389346 - GNOME crash reporter comes up on crashes, prevents breakpad

Status: RESOLVED FIXED

(Toolkit :: Startup and Profile System, defect)

Description

[Boris Zbarsky [:bzbarsky]]

BUILD:  Seamonkey build from this morning

STEPS TO REPRODUCE:
1) Start the build
2) Kill it with -SEGV

ACTUAL RESULTS: GNOME crash reporter

EXPECTED RESULTS: Breakpad, or nothing at least.

ADDITIONAL DETAILS: 

* The regression range is consistent with bug 93789
* I have libgnomeui-2.10.0-1 installed.

Comment 1

[Boris Zbarsky [:bzbarsky]]

So this is pretty annoying, especially when I'm debugging crashes.  What can we do to fix this?

Comment 2

[Mark Banner (:standard8)]

This is an annoying bug. I did find this page though:

http://library.gnome.org/devel/libgnomeui/stable/libgnomeui-gnome-ui-init.html

which means you can set:

GNOME_DISABLE_CRASH_DIALOG=1

before running SeaMonkey (or presumably Firefox etc).

It appears that:

+  char *argv[2] = { "gecko", "--disable-crash-dialog" };
+  gnome_program_init("Gecko", "1.0", libgnomeui_module_info_get(), 2, argv, NULL);

isn't working.

I'm using libgnomeui-2.12, so I'm not sure if --disable-crash-dialog is only supported in newer versions, I haven't been able to find any documentation to confirm this.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Maybe that env var should go in run-mozilla.sh ?

Comment 4

[Boris Zbarsky [:bzbarsky]]

This is worse than annoying.  Today I discovered that this bug is preventing breakpad from catching the crash, so we're losing crash data.  My test:

1)  Start today's nightly
2)  Kill it with -SEGV

if I just do that, I get a GNOME crash dialog and don't get breakpad.  If I set GNOME_DISABLE_CRASH_DIALOG=1 then I get the breakpad dialog, etc.

I've set the env var locally, but we really need to fix this if we're going to get reasonable crash data on Linux.

Comment 5

[Boris Zbarsky [:bzbarsky]]

mwu, do you want to take a stab at this regression?

Other options for fixing (harder, probably not necessary) include switching to the deprecated (but having greater functionality) gnome_init_with_popt_table.  Maybe there is some other way too, but who can tell given the suck that is the GNOME documentation?

Comment 6

[Boris Zbarsky [:bzbarsky]]

mwu and I poked at this, and libgnomeui is just buggy.  In my version, in gnome-ui-init.c, libgnomeui_pre_args_parse checks the env var and sets up the signal handlers if it's not set.  Then in libgnomeui_post_args_parse we check the arg, decide that crash reporter is disabled and don't set up the signal handler... but it's already been set up.

So we just need to add the env var, since that's the only way to disable this with some libgnomeui versions.

Comment 7

[(not currently active) Ted Mielczarek]

Attachment: set the env var in run-mozilla.sh (untested)

I don't get the Gnome crash dialog on my system, so I can't really test this.  bz or someone, would you mind trying this out?

Comment 8

[Boris Zbarsky [:bzbarsky]]

That works quite nicely, yes.  Thank you!

Comment 9

[Benjamin Smedberg]

Comment on attachment 279116 [details] [diff] [review]
set the env var in run-mozilla.sh (untested)

Boy this is sucky for XR apps. Is there a programmatic way to disable the gnome crash reporter? Anyway, r=me as a bandaid.

Comment 10

[(not currently active) Ted Mielczarek]

Checked in.  I didn't see any promising ways of dealing with this aside from the environment variable, so XR apps will probably have to use the same solution.

Comment 11

[Ben Turner (not reading bugmail, use the needinfo flag!)]

Can we use PR_SetEnv in nsXULStub to accomplish the same thing? Or is it too late to flip that variable once the app has started?