[Bug libmudflap/26446] Running large program compiled with mudflap aborts even before reaching main()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26446 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX Target Milestone|--- |4.9.0 --- Comment #10 from Andrew Pinski --- fmudflap support has been removed.
[Bug libmudflap/26446] Running large program compiled with mudflap aborts even before reaching main()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26446 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-10-24 Ever Confirmed|0 |1 --- Comment #9 from Andrew Pinski 2012-10-24 17:38:00 UTC --- I wonder if this is related to PR 51858.
[Bug libmudflap/26446] Running large program compiled with mudflap aborts even before reaching main()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26446 --- Comment #8 from Frank Ch. Eigler 2012-10-24 16:39:58 UTC --- Romain, good analysis.
[Bug libmudflap/26446] Running large program compiled with mudflap aborts even before reaching main()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26446 Romain Geissler changed: What|Removed |Added CC||romain.geissler at gmail ||dot com --- Comment #7 from Romain Geissler 2012-10-24 16:33:19 UTC --- 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.
[Bug libmudflap/26446] Running large program compiled with mudflap aborts even before reaching main()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26446 --- Comment #6 from Clément David 2012-02-08 13:49:53 UTC --- Created attachment 26611 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26611 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 0x003a0061a0ac in _gfortrani_sys_exit (code=1) at ../../../libgfortran/runtime/error.c:96 #2 0x003a0061a2d5 in _gfortrani_os_error (message=0x3a006f514f "Memory allocation failed") at ../../../libgfortran/runtime/error.c:238 #3 0x003a0061ac6f in _gfortrani_get_mem (n=) at ../../../libgfortran/runtime/memory.c:46 #4 0x003a006d92b5 in _gfortrani_init_units () at ../../../libgfortran/io/unit.c:585 #5 0x003a006185d8 in init () at ../../../libgfortran/runtime/main.c:158 #6 0x00315260f196 in call_init (l=, argc=1, argv=0x7fffe198, env=0x7fffe1a8) at dl-init.c:83 #7 0x00315260f273 in call_init (env=, argv=, argc=, l=) at dl-init.c:50 #8 _dl_init (main_map=0x3152823288, argc=1, argv=0x7fffe198, env=0x7fffe1a8) at dl-init.c:132 #9 0x00315260171a in _dl_start_user () from /lib64/ld-linux-x86-64.so.2 #10 0x0001 in ?? () #11 0x7fffe465 in ?? () #12 0x in ?? ()
[Bug libmudflap/26446] Running large program compiled with mudflap aborts even before reaching main()
--- Comment #5 from walter dot zimmer at dlr dot de 2006-04-25 14:05 --- > 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26446
[Bug libmudflap/26446] Running large program compiled with mudflap aborts even before reaching main()
--- Comment #4 from fche at redhat dot com 2006-04-22 15:37 --- (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? -- fche at redhat dot com changed: What|Removed |Added CC||fche at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26446
[Bug libmudflap/26446] Running large program compiled with mudflap aborts even before reaching main()
--- Comment #3 from walter dot zimmer at dlr dot de 2006-03-24 16:57 --- (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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26446
[Bug libmudflap/26446] Running large program compiled with mudflap aborts even before reaching main()
--- Comment #2 from walter dot zimmer at dlr dot de 2006-02-23 17:43 --- (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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26446
[Bug libmudflap/26446] Running large program compiled with mudflap aborts even before reaching main()
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-02-23 17:24 --- Mudflap needs memory to set up runtime data structures, so you simply need more (virtual) memory. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26446
