Bug 160173 - malloc intersept program is singularity behavior
malloc intersept program is singularity behavior
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: glibc (Show other bugs)
4.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-06-12 14:22 EDT by KOSAKI Motohiro
Modified: 2007-11-30 17:07 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-06-13 03:49:12 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description KOSAKI Motohiro 2005-06-12 14:22:46 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)

Description of problem:
when below sample program compile,
gcc different behaver with libc static or dynamic link.

1. gcc test.c 
    -> ok. below program output "malloc called"
2. gcc test.c -static
    -> compile error!

I think, this is bug.


-------------------------
#include <stdio.h>

void* malloc(size_t s){
   printf("malloc called\n");
}

main(){
  malloc(1);
}
----------------------------

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
see description
  

Actual Results:  see sescription

Expected Results:  I think always output "malloc called", undisturbed libc linking model.
and malloc is must interseptable because this is orthodox UNIX behaver.



Additional info:
Comment 1 Jakub Jelinek 2005-06-13 03:49:12 EDT
Static linking in Linux is meant primarily for system utilities that can't
be linked dynamically (e.g. ldconfig, prelink) or some system recovery utilities.
It is certainly not meant for use by 3rd party applications.  Statically linked
apps are usually less portable than dynamically linked ones (e.g. when they use
NSS/iconv/locales), if you need to link some particular library statically,
then -Wl,-Bstatic -lfoo -lbar -Wl,-Bdynamic is almost always a better solution.
Some other operating systems don't support static linking at all for these
reasons (e.g. Solaris).

That said, you can override malloc even with -static, but you need to override
the whole allocator, not just one selected function from it.
So, if you decide to use different malloc, you should also use a different
calloc, free, realloc, __libc_memalign at least, plus if your program uses
other allocator functions (e.g. pvalloc, memaling, posix_memalign, mallinfo,
etc., then those as well).
When you link statically, you can't use dlsym (RTLD_NEXT, "malloc") etc.
to provide your malloc implementation just as a wrapper on top of libc's
allocator, and having malloc come from one allocator and free from another one
means either that the program has no chance of working, or you rely on internal
implementation details of libc's allocator.

Note You need to log in before you can comment on or make changes to this bug.