Bug 45908 - dmalloc needs fix for strdup as macro
Summary: dmalloc needs fix for strdup as macro
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Raw Hide
Classification: Retired
Component: dmalloc   
(Show other bugs)
Version: 1.0
Hardware: i386 Linux
medium
medium
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact:
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2001-06-25 20:11 UTC by Jeff Johnson
Modified: 2007-04-18 16:33 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-07-19 14:33:19 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Jeff Johnson 2001-06-25 20:11:42 UTC
From the dmalloc mailing list:


	I ran into problems with dmalloc 4.8.2 and strdup.

Specifically, on my system (a Red Hat Linux system),
strdup() becomes a very complex macro, that can
either resolve into a call to malloc/memcpy or
into a call to __strdup.

The full macro looks like this:

#  define __strdup(s) \
   (__extension__ (__builtin_constant_p (s) && __string2_1bptr_p (s)
        \
         ? (((__const char *) (s))[0] == '\0'                        \
         ? (char *) calloc (1, 1)                                 \
              : ({ size_t __len = strlen (s) + 1;                      \
                char *__retval = (char *) malloc (__len);           \
                  if (__retval != NULL)                               \
                      __retval = (char *) memcpy (__retval, s, __len);  \
                  __retval; }))                                       \
           : __strdup (s)))


Now, the configure test determines that strdup
is a macro, and turns on DMALLOC_STRDUP_MACRO.

This basically means that in the case that we call
__strdup, we lose the memory allocation, and
all subsequent free calls appear as errors.

Turning off DMALLOC_STRDUP_MACRO manually causes
compilation errors (when we prototype strdup).

So, I guess the question is, how best to fix this?

The approach I'm planning on is to turn on
__NO_STRING_INLINES in my configure script (when dmalloc is selected),
which disables this behaviour in bits/string2.h.

Anyone have a better idea?

Comment 1 Jakub Jelinek 2001-06-26 09:56:21 UTC
The best solution is that dmalloc intercepts __strdup() as well as strdup().
glibc is allowed to do this by all standards.

Comment 2 Jakub Jelinek 2005-07-19 14:33:19 UTC
dmalloc has been removed in FC4.


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