Force crash on Mac10.9- in BreakDebugger()

Force crash on Mac10.9- in BreakDebugger()

Somehow int3 doesn't work on Mac10.9- to crash the process and let the
browser process know the crash. Force crash instead.

BUG=644303

[Xianzhu, 2016-09-07 23:07:32]

The CQ bit was checked by wangxianzhu@chromium.org to run a CQ dry run

[Xianzhu, 2016-09-07 23:08:08]

Description was changed from

==========
Force crash on Mac10.9- in BreakDebugger()

Somehow int3 doesn't work on Mac10.9- to crash the process and let the
browser process know the crash. Force crash instead.

BUG=644303
==========

to

==========
Force crash on Mac10.9- in BreakDebugger()

Somehow int3 doesn't work on Mac10.9- to crash the process and let the
browser process know the crash. Force crash instead.

BUG=644303
==========

[commit-bot: I haz the power, 2016-09-07 23:08:10]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Xianzhu, 2016-09-07 23:08:51]

wangxianzhu@chromium.org changed reviewers:
+ dcheng@chromium.org

[commit-bot: I haz the power, 2016-09-07 23:19:12]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-09-07 23:19:12]

Dry run: Try jobs failed on following builders:
  ios-device on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-device/builds...)

[Xianzhu, 2016-09-07 23:23:13]

Patchset #6 (id:100001) has been deleted

[Xianzhu, 2016-09-07 23:23:30]

The CQ bit was checked by wangxianzhu@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-09-07 23:24:34]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-09-07 23:28:49]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-09-07 23:28:50]

Dry run: Try jobs failed on following builders:
  chromium_presubmit on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)

[dcheng, 2016-09-08 05:08:29]

dcheng@chromium.org changed reviewers:
+ rsesek@chromium.org, thakis@chromium.org

[dcheng, 2016-09-08 05:08:29]

I'm not a good reviewer for this, but I'm adding some Mac people who should know
a lot more about this.

That being said, I'm pretty sure dereferencing null is undefined behavior in
C++, which means the compiler could do strange things. Do we have any idea why
this isn't working on Mac?

[Xianzhu, 2016-09-08 23:14:04]

On 2016/09/08 05:08:29, dcheng wrote:
> I'm not a good reviewer for this, but I'm adding some Mac people who should
know
> a lot more about this.
> 
> That being said, I'm pretty sure dereferencing null is undefined behavior in
> C++, which means the compiler could do strange things. Do we have any idea why
> this isn't working on Mac?

We are using null-dereference to force crash in official release build (non-gcc
and non-clang): https://cs.chromium.org/chromium/src/base/logging.h?rcl=0&l=463.
There are also other null-dereference code:
https://cs.chromium.org/search/?q=%22*)0+%3D%22&sq=package:chromium&type=cs and
https://cs.chromium.org/search/?q=%22*%3E(0)+%3D%22&sq=package:chromium&type=cs.

The changed code applies to non-official or debug build only.

No idea what's going on on Mac 10.9. Just guessed the reason and tried on try
bots with various method in https://codereview.chromium.org/2312393002/, and
found that the patch in this CL just worked.

[dcheng, 2016-09-09 05:15:50]

https://codereview.chromium.org/2315403002/diff/140001/base/debug/stack_trace...
File base/debug/stack_trace_posix.cc (left):

https://codereview.chromium.org/2315403002/diff/140001/base/debug/stack_trace...
base/debug/stack_trace_posix.cc:377: if (::signal(signal, SIG_DFL) == SIG_ERR)
Why is this change necessary as well?

[Xianzhu, 2016-09-09 05:20:13]

https://codereview.chromium.org/2315403002/diff/140001/base/debug/stack_trace...
File base/debug/stack_trace_posix.cc (left):

https://codereview.chromium.org/2315403002/diff/140001/base/debug/stack_trace...
base/debug/stack_trace_posix.cc:377: if (::signal(signal, SIG_DFL) == SIG_ERR)
On 2016/09/09 05:15:50, dcheng wrote:
> Why is this change necessary as well?

Without this, the forced crash will be ignored.

At least on Mac10.9, ::signal(signal, SIG_DFL) seems to just restore the
original signal handler but not to reraise the signal. Based on my test, if
::signal(signal, SIG_DFL) is successful, this function just returns, and nothing
happens. _exit(1) will let the program crash.

[Robert Sesek, 2016-09-09 14:52:20]

Have you checked what processes are running when the TIMEOUT occurs? I'm
wondering if ReportCrash is trying to generate a crash report, which is
preventing the process from being reaped and reported as a crash.

[Xianzhu, 2016-09-09 15:59:51]

On 2016/09/09 14:52:20, Robert Sesek wrote:
> Have you checked what processes are running when the TIMEOUT occurs? I'm
> wondering if ReportCrash is trying to generate a crash report, which is
> preventing the process from being reaped and reported as a crash.

I don't have a debugging environment on Mac10.9, so what I did was just trying
different measures on the try bot.

Will appreciate if anyone having a Mac10.9 can help to debug this. Will try to
find a way to prove the ReportCrash theory on try bot.

[Xianzhu, 2016-09-09 18:53:55]

On 2016/09/09 15:59:51, Xianzhu wrote:
> On 2016/09/09 14:52:20, Robert Sesek wrote:
> > Have you checked what processes are running when the TIMEOUT occurs? I'm
> > wondering if ReportCrash is trying to generate a crash report, which is
> > preventing the process from being reaped and reported as a crash.
> 
> I don't have a debugging environment on Mac10.9, so what I did was just trying
> different measures on the try bot.
> 
> Will appreciate if anyone having a Mac10.9 can help to debug this. Will try to
> find a way to prove the ReportCrash theory on try bot.

Sorry, I found no feasible way to debug ReportCrash with try bot only.

+cc dpranke@, qyearsley@

How long will be keep 10.9 waterfall bots (while there is no 10.9 CQ bot)?

Would you accept to land this temporary and revert it when we no longer run 10.9
bots?

[Nico, 2016-09-09 18:56:12]

On 2016/09/09 18:53:55, Xianzhu wrote:
> On 2016/09/09 15:59:51, Xianzhu wrote:
> > On 2016/09/09 14:52:20, Robert Sesek wrote:
> > > Have you checked what processes are running when the TIMEOUT occurs? I'm
> > > wondering if ReportCrash is trying to generate a crash report, which is
> > > preventing the process from being reaped and reported as a crash.
> > 
> > I don't have a debugging environment on Mac10.9, so what I did was just
trying
> > different measures on the try bot.
> > 
> > Will appreciate if anyone having a Mac10.9 can help to debug this. Will try
to
> > find a way to prove the ReportCrash theory on try bot.
> 
> Sorry, I found no feasible way to debug ReportCrash with try bot only.
> 
> +cc dpranke@, qyearsley@
> 
> How long will be keep 10.9 waterfall bots (while there is no 10.9 CQ bot)?
> 
> Would you accept to land this temporary and revert it when we no longer run
10.9
> bots?

We still support OS X 10.9 (we dropped support for 10.7 just half a year ago:
https://chrome.googleblog.com/2015/11/updates-to-chrome-platform-support.html),
so we're going to keep the 10.9 bots for the foreseeable future.

This patch looks questionable to me. If you can't debug 10.9 changes, maybe you
can revert whatever caused the test to fail until you can?

[Xianzhu, 2016-09-09 19:05:40]

On 2016/09/09 18:56:12, Nico wrote:
> On 2016/09/09 18:53:55, Xianzhu wrote:
> > On 2016/09/09 15:59:51, Xianzhu wrote:
> > > On 2016/09/09 14:52:20, Robert Sesek wrote:
> > > > Have you checked what processes are running when the TIMEOUT occurs? I'm
> > > > wondering if ReportCrash is trying to generate a crash report, which is
> > > > preventing the process from being reaped and reported as a crash.
> > > 
> > > I don't have a debugging environment on Mac10.9, so what I did was just
> trying
> > > different measures on the try bot.
> > > 
> > > Will appreciate if anyone having a Mac10.9 can help to debug this. Will
try
> to
> > > find a way to prove the ReportCrash theory on try bot.
> > 
> > Sorry, I found no feasible way to debug ReportCrash with try bot only.
> > 
> > +cc dpranke@, qyearsley@
> > 
> > How long will be keep 10.9 waterfall bots (while there is no 10.9 CQ bot)?
> > 
> > Would you accept to land this temporary and revert it when we no longer run
> 10.9
> > bots?
> 
> We still support OS X 10.9 (we dropped support for 10.7 just half a year ago:
>
https://chrome.googleblog.com/2015/11/updates-to-chrome-platform-support.html),
> so we're going to keep the 10.9 bots for the foreseeable future.
> 
> This patch looks questionable to me. If you can't debug 10.9 changes, maybe
you
> can revert whatever caused the test to fail until you can?

The only test (harness-tests/crash.html) can easily reproduce the issue was
added a week ago when I noticed the problem. The problem might be very old,
perhaps even not a regression so there might not be any CL to revert.

This is similar to crbug.com/619153 which also doesn't look like a regression.

[Xianzhu, 2016-09-10 02:43:20]

OK. Let's just wait for the end of support of Mac 10.9.

[Nico, 2016-09-10 03:18:18]

That's years away.

On Sep 9, 2016 10:43 PM, <wangxianzhu@chromium.org> wrote:

> OK. Let's just wait for the end of support of Mac 10.9.
>
> https://codereview.chromium.org/2315403002/
>

-- 
You received this message because you are subscribed to the Google Groups
"Chromium-reviews" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[Xianzhu, 2016-09-10 03:26:11]

On 2016/09/10 03:18:18, Nico wrote:
> That's years away.

There are few layout tests having Crash expectations on Mac. Perhaps we can just
live with [ Crash Timeout ] expectations for them. No one seemed to have noticed
this before I encountered it, so it seems not important at all.

Anyone interested and having time and debugging environment is welcome to take
over the bug.

> 
> On Sep 9, 2016 10:43 PM, <mailto:wangxianzhu@chromium.org> wrote:
> 
> > OK. Let's just wait for the end of support of Mac 10.9.
> >
> > https://codereview.chromium.org/2315403002/
> >
> 
> -- 
> You received this message because you are subscribed to the Google Groups
> "Chromium-reviews" group.
> To unsubscribe from this group and stop receiving emails from it, send an
email
> to mailto:chromium-reviews+unsubscribe@chromium.org.