Linux: Guess the thread id for crashing renderers in a different PID namespac...

Linux: Guess the thread id for crashing renderers in a different PID namespace.

BUG=48997
TEST=Google Chrome gets valid crash reports for about:crash most of the time.

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=52723

[Lei Zhang, 2010-07-14 16:52:48]

I can't think of a way to get translate the TID between the renderer's pid
namespace and the browser's. Any thoughts on this?

[agl, 2010-07-15 17:31:14]

It's been too long. Remind me again why we need the crashing TID?

And I'm afraid that I don't know of any way to translate. I had thought that an
SCM_CREDENTIALS messages would have translated PIDs at least, but no.

My best bet would be to set the signal mask to something crazy at crash time,
then look in /proc/<pid>/task/*/status for the thread with the magic mask.
(Yuck!)

http://codereview.chromium.org/2961008/diff/1/2
File chrome/browser/crash_handler_host_linux.cc (right):

http://codereview.chromium.org/2961008/diff/1/2#newcode195
chrome/browser/crash_handler_host_linux.cc:195: if (actual_crashing_pid !=
crashing_pid) {
actual_crashing_pid appears to always be -1 at this point. That seems odd.

[Lei Zhang, 2010-07-15 22:16:56]

On 2010/07/15 17:31:14, agl wrote:
> It's been too long. Remind me again why we need the crashing TID?
> 
> And I'm afraid that I don't know of any way to translate. I had thought that
an
> SCM_CREDENTIALS messages would have translated PIDs at least, but no.

context.tid gets set in ExceptionHandler::HandleSignal(), i.e. context.tid = 3
for a crashing renderer. The entire context is passed over to the browser, which
hands it off to google_breakpad::WriteMinidump(). There, we create a
MinidumpWriter with crashing_tid_ = 3, and it goes wrong from there because we
do everything in terms of the "real" pids.

> My best bet would be to set the signal mask to something crazy at crash time,
> then look in /proc/<pid>/task/*/status for the thread with the magic mask.
> (Yuck!)

Ah, I didn't know that's what's inside /proc/<pid>/task. I will take a look and
try to avoid killing kittens.

http://codereview.chromium.org/2961008/diff/1/2
File chrome/browser/crash_handler_host_linux.cc (right):

http://codereview.chromium.org/2961008/diff/1/2#newcode195
chrome/browser/crash_handler_host_linux.cc:195: if (actual_crashing_pid !=
crashing_pid) {
On 2010/07/15 17:31:14, agl wrote:
> actual_crashing_pid appears to always be -1 at this point. That seems odd.

Fixed typos.

[Lei Zhang, 2010-07-16 03:17:34]

Please see patch set 3. I'm reading /proc/[pid]/task/*/syscall. Not sure if this
is better or worse than setting the signal mask.

[agl, 2010-07-16 12:43:25]

LGTM

http://codereview.chromium.org/2961008/diff/8001/4002
File base/linux_util.cc (right):

http://codereview.chromium.org/2961008/diff/8001/4002#newcode283
base/linux_util.cc:283: if (0 == strncmp(expected_data.c_str(),
syscall_data.get(),
Based on the description of the function, I expected this to be a memcmp.
However, syscall is a textual function so it doesn't really matter.