Closed Bug 389346 Opened 14 years ago Closed 14 years ago

GNOME crash reporter comes up on crashes, prevents breakpad

Categories

(Toolkit :: Startup and Profile System, defect)

x86
Linux
defect
Not set
critical

Tracking

()

RESOLVED FIXED

People

(Reporter: bzbarsky, Assigned: ted)

References

Details

(Keywords: regression)

Attachments

(1 file)

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.
Keywords: regression
So this is pretty annoying, especially when I'm debugging crashes.  What can we do to fix this?
Flags: blocking1.9?
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.
Maybe that env var should go in run-mozilla.sh ?
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.
Severity: normal → critical
Summary: GNOME crash reporter comes up on crashes → GNOME crash reporter comes up on crashes, prevents breakpad
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?
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.
Assignee: nobody → ted.mielczarek
Flags: blocking1.9? → blocking1.9+
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?
That works quite nicely, yes.  Thank you!
Attachment #279116 - Flags: review?(benjamin)
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.
Attachment #279116 - Flags: review?(benjamin) → review+
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.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
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?
Component: XRE Startup → Startup and Profile System
QA Contact: xre.startup → startup
You need to log in before you can comment on or make changes to this bug.