GNOME Bugzilla – Bug 664695
gst-inspect tries to allocate 6.1 GB of heap
Last modified: 2011-11-27 17:19:35 UTC
I'm trying to build and use GStreamer 0.10.35 on OS X using jhbuild and gtk-osx-build's modulesets-stable. I get an out of memory error when the build invokes gobject-introspection. Apparently it wants 6.1 GB of heap, which I don't have. Here's the error: GLib-ERROR **: gmem.c:405: overflow allocating 1635021569*4 bytes Command '['/Users/fliep/gtk/source/gstreamer-0.10.35/gst/tmp-introspectA6R0qs/Gst-0.10', '--introspect-dump=/Users/fliep/gtk/source/gstreamer-0.10.35/gst/tmp-introspectA6R0qs/functions.txt,/Users/fliep/gtk/source/gstreamer-0.10.35/gst/tmp-introspectA6R0qs/dump.xml']' returned non-zero exit status -5 I thought I could solve it simply by reconfiguring with --disable-introspection and go my merry way, which worked, until I needed gst-inspect for the configure script of another program that I want to build. That also wants to allocate a huge amount of memory: $ gst-inspect-0.10 GLib-ERROR **: gmem.c:405: overflow allocating 1635021569*4 bytes Trace/BPT trap Here's a backtrace of the gst-inspect crash:
+ Trace 229117
I'm running Mac OS X Snow Leopard (10.6.8), with GLib 2.30.1. I've configured GStreamer like this: ./configure --prefix /Users/fliep/gtk/inst --libdir /Users/fliep/gtk/inst/lib --disable-tests --disable-introspection I've found only one page by googling the error message: http://forum.processing.org/topic/gsvideo-0-9-glgraphics-0-99 (Ctrl-F for 'gmem.c') and it seems the problem is specific to Snow Leopard. Looks like nobody found a solution there, though.
This looks like a corrupted GStreamer registry. Could you upload the registry file?
Created attachment 202087 [details] Corrupt registry file That did it; if I renamed ~/.gstreamer/registry.x86_64.bin then it worked. I've attached the non-working registry file. It's odd that it's named x86_64 when I'm building a 32-bit GStreamer. I did build a 64-bit one in the recent past, so I thought that the registry file may have been left over from that build, and therefore unreadable; but I looked at the new registry file that was created when I removed the old one, and it was also named x86_64. Could that be part of the problem perhaps?
Interesting. Does building with introspection enabled now work too?
Indeed it does.
Maybe the architecture detection code doesn't work correctly on OS X. Did you run a 32 bit OS X or did you run a 32 bit GStreamer in 64 bit OS X? Could you check if this creates a x86_64-named registry file again? The reason for the too large memory allocation could be, that the 32 bit registry was named x86_64 and then later was tried to be loaded by a 64 bit GStreamer.
Yes, I'm now running a 32-bit GStreamer in 64-bit OS X. It did indeed create another x86_64-named registry file. I expect the memory error was caused by the exact opposite: the 64-bit registry file was left over from when I had built a 64-bit GStreamer, and then the 32-bit GStreamer, thinking its architecture was x86_64, tried to load it.
What's the value of HOST_CPU in config.h of the 32 bit and 64 bit build? This looks like a bug in autoconf's AC_CANONICAL_HOST
And check in config.log for both builds for lines like: configure:3548: checking build system type configure:3562: result: x86_64-unknown-linux-gnu configure:3582: checking host system type configure:3595: result: x86_64-unknown-linux-gnu What is the result for both builds?
The problem is likely that Apple uses a custom compiler flag, -arch, to set the compile architectures (the choices are x86_64, i386, ppc, and ppc_64). It can handle more than one and in most cases will automatically build "universal" binaries (multiple binaries for different architectures lipoed together into a single file, which the linker knows how to handle to find the appropriate binary for the architecture it's running). That part all seems to be working, but your configuration doesn't know about it and is using the values of host and build to set filenames and to determine when to rebuild the registry file.
In the 32-bit build, config.h has HOST_CPU defined to "x86_64". In config.log, the test results are like so: configure:3544: checking build system type configure:3558: result: x86_64-apple-darwin10.8.0 configure:3578: checking host system type configure:3591: result: x86_64-apple-darwin10.8.0 I don't have the 64-bit build anymore, and it's somewhat of a pain to set up that build environment again, so I may not get around to that for a while.
Ok, so this is clearly an autoconf bug, either of upstream autoconf or the version used on OS X. Could you forward this bug to: http://www.gnu.org/s/autoconf/#bug