This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug libmudflap/26446] Running large program compiled with mudflap aborts even before reaching main()
- From: "romain.geissler at gmail dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Wed, 24 Oct 2012 16:33:19 +0000
- Subject: [Bug libmudflap/26446] Running large program compiled with mudflap aborts even before reaching main()
- Auto-submitted: auto-generated
- References: <bug-26446-4@http.gcc.gnu.org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26446
Romain Geissler <romain.geissler at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |romain.geissler at gmail
| |dot com
--- Comment #7 from Romain Geissler <romain.geissler at gmail dot com> 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.