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 attachment 107204 [details] /usr/libexec/beep-media-player-2-bin --no-log output
Created attachment 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 attachment 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.
