?
This directory is not cleaned up. It's a real mess in fact. :) Note
that these are small memory dumps, not the full ones.
Making the dumps available would mean to add a step to copy the dump
back to the main server and let these files live on the server.
Patches are welcome but I don't see a strong incentive.
M-A
On Fri, Apr 17, 2009 at 3:14 PM, Huan Ren <hu...@google.com> wrote:
> Right it is generated but then next UI test case will clean up the
> directory to detect new crashes. It is easy to change the behavior to
> something like backing up crash dumps at the end of each test case.
> What we need is some place in try server or buildbot to save the crash
> dumps and adding a link in the test output. Maybe there are some other
> better options for try server since it does not build with symbols.
> What about buildbot?
>
> Huan
>
> On Fri, Apr 17, 2009 at 12:00 PM, Marc-Antoine Ruel <mar...@chromium.org>
> wrote:
>> The memory dumps _are_ generated. They are just not accessible at the moment.
>>
>> For example on XP, they are on %HOMEPATH%\Local Settings\Application
>> Data\Chromium\User Data\Crash Reports.
>>
>> If there is interest, we could investigate to have the crash dumps
>> available for public consumption but in general, if the bug is not
>> reproducible locally, it's easier to just debug on the slave.
>> Debugging a crash dump requires the symbols, which is a relatively
>> large download, slowing down the efficiency of this method. So I'm not
>> sure it's a good idea at all.
>>
>> The try server (at least on windows) don't build with symbols to be
>> faster so the memory dumps wouldn't be of much use.
>>
>> M-A
>>
>> On Thu, Apr 16, 2009 at 6:22 PM, Huan Ren <hu...@google.com> wrote:
>>>
>>> I am trying to improve the UI automation framework with the goal of
>>> reducing disabled UI test from 42 to 10 and running time (xp release)
>>> from 400s to 200s. Following is a list of issues I found so far (I am
>>> still studying them):
>>>
>>> 1. Many UI commands are executed asynchronously, and test client
>>> sleeps and polls (not always polls actually) the result. This process
>>> is slow and error prone. And we need different timeout for release,
>>> debug, and purify.
>>> 2. The mechanism to send command to certain window/tab is not
>>> reliable. For example, I found GetLastActiveBrowserWindow and
>>> ActivateTab don't work as intended.
>>> 3. UI_tests.exe, crash_service.exe, and chrome.exe share the same
>>> mutex when writing log file. This makes things slow. In addition, when
>>> a process crashes/shutdowns while writing log files, other process
>>> will get WAIT_ABANDONED when waiting for mutex and this leads to an
>>> infinite loop.
>>> 4. If Chrome crashes when running the test on buildbot, we can not
>>> investigate the cause. This might be exact the situation we'd like the
>>> test to catch but we have to disable the test most of the time.
>>>
>>> The biggest pain I have is that when UI tests fail/crash on buildbot
>>> or try server, we have little information to investigate. I would
>>> image lots of people faced similar situation in the past and ended up
>>> with disabling the test. I'd think we need to address this issue first
>>> before making good improvement on UI tests. If we have good debugging
>>> infrastructure in place, fixing UI flakiness is much easier. As a
>>> minimal, we need to save crash dumps. Any thoughts on this?
>>>
>>> Huan
>>>
>>> >>>
>>>
>>
>
--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
