On Wed, Jun 16, 2010 at 3:27 PM, Maciej Stachowiak m...@apple.com wrote:
On Jun 16, 2010, at 2:04 PM, Eric Seidel wrote:
We could add a separate option to DumpRenderTree to disable
ReportCrash (sign up for all the crashing signals and simply exit(2)
or similar). That would be useful in
Hi Ojan.
I wonder if it would help to distinguish --exit-after-n-failures from
--exit-after-n-crashes.
I think that crashing tests are the biggest problem, since they can cause a bot
to lag behind quite a bit.
Geoff
On Jun 16, 2010, at 1:57 PM, Ojan Vafai wrote:
Currently,
We could add a separate option to DumpRenderTree to disable
ReportCrash (sign up for all the crashing signals and simply exit(2)
or similar). That would be useful in many instances besides the bots.
Yes, --exit-after-N-failures was designed to prevent crashers from
eating the bots.
On Wed, Jun
We could also look into BreakPad (Chromium's solution) for the bots.
That doesn't seem to hang for 5 minutes a crash like ReportCrash does.
But maybe that's related to how Chromium builds (symbol-wise) more
than ReportCrash.
On Wed, Jun 16, 2010 at 2:04 PM, Eric Seidel e...@webkit.org wrote:
We
On Jun 16, 2010, at 2:04 PM, Eric Seidel wrote:
We could add a separate option to DumpRenderTree to disable
ReportCrash (sign up for all the crashing signals and simply exit(2)
or similar). That would be useful in many instances besides the bots.
Yes, --exit-after-N-failures was designed
I think --exit-after-N-failures is actually very useful as-is. I
think peopel just use it for different things. For teh commit-queue
--exit-after-N-failures is great for keeping it quick.
Perhaps people want to use the bots more like try-bots and have
--exit-after-N-failures higher.
I think
6 matches
Mail list logo
