[Bug libmudflap/26446] New: Running large program compiled with mudflap aborts even before reaching main()

[Bug libmudflap/26446] New: Running large program compiled with mudflap aborts even before reaching main()

[walter dot zimmer at dlr dot de]

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.


-- 
           Summary: Running large program compiled with mudflap aborts even
                    before reaching main()
           Product: gcc
           Version: 4.1.0
            Status: UNCONFIRMED
          Severity: minor
          Priority: P3
         Component: libmudflap
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: walter dot zimmer at dlr dot de
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26446

[Bug libmudflap/26446] Running large program compiled with mudflap aborts even before reaching main()

[rguenth at gcc dot gnu dot org]

------- 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

[Bug libmudflap/26446] Running large program compiled with mudflap aborts even before reaching main()

[walter dot zimmer at dlr dot de]

------- 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()

[walter dot zimmer at dlr dot de]

------- 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()

[fche at redhat dot com]

------- 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()

[walter dot zimmer at dlr dot de]

------- 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()

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26446

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |WONTFIX
   Target Milestone|---                         |4.9.0

--- Comment #10 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
fmudflap support has been removed.

[Bug libmudflap/26446] Running large program compiled with mudflap aborts even before reaching main()

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26446

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2012-10-24
     Ever Confirmed|0                           |1

--- Comment #9 from Andrew Pinski <pinskia at gcc dot gnu.org> 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()

[fche at redhat dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26446

--- Comment #8 from Frank Ch. Eigler <fche at redhat dot com> 2012-10-24 16:39:58 UTC ---
Romain, good analysis.

[Bug libmudflap/26446] Running large program compiled with mudflap aborts even before reaching main()

[romain.geissler at gmail dot com]

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.

[Bug libmudflap/26446] Running large program compiled with mudflap aborts even before reaching main()

[c.david86 at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26446

--- Comment #6 from Clément David <c.david86 at gmail dot com> 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  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 ?? ()