Bugzilla Bug 162405

The latest release of BMPx dies on two machines I've tried running it on (one
is 64 bit, the other isn't; output here will be from the 64 bit machine).

Basically, BMPx will show its splash screen, get to the stage where it ought to
open the GUI, then pop up a crash dialogue. The dialogue suggests running
"/usr/libexec/beep-media-player-2-bin --no-log", which gives the attached
output.

Reproducible: Always

Steps to Reproduce:
1. Emerge BMPx.
2. Run BMPx.
3. Crash!

Actual Results:  
The above.

Expected Results:  
Er... the UI?

The BMPx project has recently instated a "policy" of rejecting bug reports from
Gentoo users who haven't already raised the issue on Gentoo's own bugzilla. I
do find this a little irritating, especially seeing as the ebuild in question
doesn't apply any patches, but I can also see some degree of sense - and also
don't know how big a "problem" this has been for the project.

I fully expect this to be passed upstream fairly sharpish, but you never
know...

Created an attachment (id=107204) [details]
 /usr/libexec/beep-media-player-2-bin --no-log output

Created an attachment (id=107206) [details]
emerge --info

You need to build it with USE="debug" and run
/usr/libexec/beep-media-player-2-bin in gdb and provide meaningfull backtrace
or this is all worthless.

(In reply to comment #3)
> You need to build it with USE="debug" and run
> /usr/libexec/beep-media-player-2-bin in gdb and provide meaningfull backtrace
> or this is all worthless.
> 

Will get on it sharpish. I had some strace output, but didn't think that would
be meaningful, and was unsure of the recommended next step. :)

See http://www.gentoo.org/proj/en/qa/backtraces.xml and reopen when ready....
;)

Created an attachment (id=107224) [details]
Backtrace of segfault when creating UI

Hrm. Building in debug mode seemed to slightly change the nature of the bug;
now, instead of a "guaranteed" segfault, occasionally it will simply go into a
busy loop instead of opening the UI (but not apparently crash). I've left it
for a few minutes and it doesn't appear to be in any hurry to actually open the
window.

Anyway, I have attached a backtrace. I turned off my CFLAGS during the build,
so it ought to be sane, but it doesn't mean much to me - not surprising seeing
as I haven't actually programmed using Glade or GNOME libs directly. Please,
tell me I won't need to rebuild half of GNOME in debug mode to get readable
output :P

> as I haven't actually programmed using Glade or GNOME libs directly. Please,
> tell me I won't need to rebuild half of GNOME in debug mode to get readable
> output :P

Because I'm not sure is that enough or not I'm going to review this bug with
upstream soon as upstream is actually available.. he is currently without
internet connection at home and is online only occasionally. Besides, he is
preparing 0.40 release and if this is an actual bug I'm sure he wants to fix
this before releasing.

Also not sure if this applies to you or not but note that if you recently
upgraded from GCC 3.4.x to GCC 4.x, you need to rebuild all C++ libraries
(pretty much means you have to rebuild world, sorry) because libstdc++.so.6
layer has been changed and is not backwards entirely compatible (it should be,
but it isn't). Also note that this breakage is beyond revdep-rebuild
capabilities to fix as library name has not been changed (it should have been,
in my opinion).

ok, I've just committed 0.40.0_rc3 to tree, this bug should be gone with it.