Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 160173 - malloc intersept program is singularity behavior
Summary: malloc intersept program is singularity behavior
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: glibc
Version: 4.0
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
: ---
Assignee: Jakub Jelinek
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-06-12 18:22 UTC by KOSAKI Motohiro
Modified: 2007-11-30 22:07 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-06-13 07:49:12 UTC


Attachments (Terms of Use)

Description KOSAKI Motohiro 2005-06-12 18:22:46 UTC
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 07:49:12 UTC
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.