Hide Forgot
abrt version: 1.1.14 architecture: x86_64 Attached file: backtrace cmdline: /usr/bin/python2.7 ./gottengeography component: python crash_function: malloc_consolidate executable: /usr/bin/python2.7 kernel: 2.6.35.10-74.fc14.x86_64 package: python-2.7-8.fc14.1 rating: 4 reason: Process /usr/bin/python2.7 was killed by signal 11 (SIGSEGV) release: Fedora release 14 (Laughlin) How to reproduce: I closed a PyGobject/introspection based python app. time: 1295056633 uid: 500
Created attachment 473621 [details] File: backtrace
Package: python-2.7-8.fc14.1 Architecture: x86_64 OS Release: Fedora release 14 (Laughlin) How to reproduce ----- something something pygobject introspection blah blah
Thanks for filing this bug report. Looking at the backtrace, it looks like something within the process has corrupted the heap. This leads to a crash, in thread #0, when pulseaudio attempts to allocate memory (I don't think it's puleaudio's fault; I think the heap has been trashed by something else). Looking at the memory map in attachment 473621 [details], I see numerous libraries below /opt/gnome/ are mapped into memory. It looks like you're running a non-standard build of the gnome libraries, perhaps you built these locally? As is, this is likely to be a bug in one of those libraries. This kind of thing is hard to track down. I'd recommend using valgrind to figure things out further. Given that this problem is most likely in a non-Fedora build of Gnome, I'm going to close this bug out as NOTABUG (on the grounds that the bug is not in Fedora). Hope that makes sense.
Yeah, I am running GNOME from a jhbuild environment, sorry for the noise. I'm developing a simple python script that should not be doing anything terribly difficult or unusual, but I'm doing it with all the latest git pygobject and gnome-instrospection toys. Do you think this report would be valuable upstream, or do you think this would be a fairly obvious problem for them to fix on their own without my report? Thanks.
This seems like a bug for upstream, but I don't think it's going to be very useful to them without more information. My recommendation is that you should try to run python under valgrind when replicating this. valgrind /usr/bin/python PATH_TO_SCRIPT Hopefully that should show the error (along with quite a bit of other noise, alas).