We're currently trying to get our binary mudflapped with gcc 4.1-20060217. Compiling with -fmudflap works (for the C code; FFLAGS omits -fmudflap), linking with -lmudflap is also no problem. When calling the binary, we get: bash> ./testbin Operating system error: Success Memory allocation failed Gdb tells me that it doesn't even reach main(), and the mudflap environment variables have no effect. I guess mudflap just gives up when beeing used on such a large binary, but I don't find anything on this error messages on google and I wonder if it's documented somewhere. In any case, if the cause is a memory allocation problem of mudflap, perhaps the error message should be more specific about what one can do or it should be documented somewhere, so perhaps this is only a documentation enhancement request. If on the other hand debugging of a 4 mb executable should be supported, I wonder what I can do to trace this error down.
Mudflap needs memory to set up runtime data structures, so you simply need more (virtual) memory.
(In reply to comment #1) > Mudflap needs memory to set up runtime data structures, so you simply need more > (virtual) memory. Ok, I understand. Thanks! > cat /proc/meminfo MemTotal: 4038480 kB [...] SwapTotal: 8385912 kB Seems like adding even more memory is no simple task :) A quick calculation on the other hand rises the question, if this much memory shouldn't be enough. It's about 3000 times the memory of the application (4mb). Are there any tricks how to get mudflap to use less memory? Variables don't work, as it exits before evaluating them, so it would have to be a compile time option. Sadly, this is already a reduced version of our binary, so we can't get this smaller, so I guess we have to do without mudflap's services.
(In reply to comment #1) > Mudflap needs memory to set up runtime data structures, so you simply need more > (virtual) memory. I investigated further and found that it is not the size of the memory that matters. The problem seems to be that we also use fortran code, which is not mudflapped, but needs the gfortran library. The mudflapped C code uses malloc(), which gets wrapped into calls to __mfwrap_malloc(). Unfortunately, libgfortran also uses malloc(), which is instrumented by libmudflap but shouldn't, as this exactly is causing the error. One workaround is to use g77 instead of gfortran, as libg2c apparently doesn't call malloc(). The other proposal we came up with is to link the fortran part as dynamic library at runtime, but we didn't try this yet. Therefore, I guess this is not a bug in mudflap.
(In reply to comment #3) > > I investigated further and found that it is not the size of the memory that > matters. The problem seems to be that we also use fortran code, which is not > mudflapped, but needs the gfortran library. The mudflapped C code uses > malloc(), which gets wrapped into calls to __mfwrap_malloc(). Unfortunately, > libgfortran also uses malloc(), which is instrumented by libmudflap but > shouldn't, as this exactly is causing the error. The link-time wrapping of malloc is designed precisely so that other uninstrumented libraries that call malloc by name still get registered in the libmudflap runtime. That way, pointers from these libraries may make their way to an instrumented routine, and be used without error. Does MUDFLAP_OPTIONS=-trace-calls produce anything?
> The link-time wrapping of malloc is designed precisely so that other > uninstrumented libraries that call malloc by name still get registered in the > libmudflap runtime. That way, pointers from these libraries may make their way > to an instrumented routine, and be used without error. Good idea. Seems to work with g77, but not with gfortran. Is there maybe any known project which uses both g++ and gfortran and still works with mudflap? > Does MUDFLAP_OPTIONS=-trace-calls produce anything? Well, it doesn't seem to reach the point where it evaluates MUDFLAP_OPTIONS, as even MUDFLAP_OPTIONS="-help" doesn't work.
Created attachment 26611 [details] Test case I'm able to reproduce with gcc 4.6.2 with a simple test case. The attached conftest.cpp check arpack 3 [http://forge.scilab.org/index.php/p/arpack-ng/] presence. I'm able to catch the following backtrace : #0 __GI_exit (status=1) at exit.c:100 #1 0x0000003a0061a0ac in _gfortrani_sys_exit (code=1) at ../../../libgfortran/runtime/error.c:96 #2 0x0000003a0061a2d5 in _gfortrani_os_error (message=0x3a006f514f "Memory allocation failed") at ../../../libgfortran/runtime/error.c:238 #3 0x0000003a0061ac6f in _gfortrani_get_mem (n=<optimized out>) at ../../../libgfortran/runtime/memory.c:46 #4 0x0000003a006d92b5 in _gfortrani_init_units () at ../../../libgfortran/io/unit.c:585 #5 0x0000003a006185d8 in init () at ../../../libgfortran/runtime/main.c:158 #6 0x000000315260f196 in call_init (l=<optimized out>, argc=1, argv=0x7fffffffe198, env=0x7fffffffe1a8) at dl-init.c:83 #7 0x000000315260f273 in call_init (env=<optimized out>, argv=<optimized out>, argc=<optimized out>, l=<optimized out>) at dl-init.c:50 #8 _dl_init (main_map=0x3152823288, argc=1, argv=0x7fffffffe198, env=0x7fffffffe1a8) at dl-init.c:132 #9 0x000000315260171a in _dl_start_user () from /lib64/ld-linux-x86-64.so.2 #10 0x0000000000000001 in ?? () #11 0x00007fffffffe465 in ?? () #12 0x0000000000000000 in ?? ()
This might comes from initialization of global and/or static variables by external libs before mudflap is initialized. Indeed, libmudflap might be already loaded by the dynamic linker, thus having many libc symbols wrapped like malloc calls for example. Mudflap does indeed provide a basic allocator that's used before even __mf_init is called, just have a look at __mf_0fn_malloc defined in mf-hooks1.c http://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libmudflap/mf-hooks1.c;h=3dd332e12c6b8ced877e7063eccb84f82e6b9699;hb=76d77f1ecada29e571ec46fd8aaa9f83cd4da4f5 it allows only 10 malloc calls before return NULL --> that's your bad alloc error. Try tweaking your linker so that mudflap gets initialized first. GNU ld have an option -zinitfirst that might be helpful, i didn't try it by myself though.
Romain, good analysis.
I wonder if this is related to PR 51858.
fmudflap support has been removed.