Bug 45908 - dmalloc needs fix for strdup as macro
dmalloc needs fix for strdup as macro
Product: Red Hat Raw Hide
Classification: Retired
Component: dmalloc (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Depends On:
  Show dependency treegraph
Reported: 2001-06-25 16:11 EDT by Jeff Johnson
Modified: 2007-04-18 12:33 EDT (History)
0 users

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

Attachments (Terms of Use)

  None (edit)
Description Jeff Johnson 2001-06-25 16:11:42 EDT
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 05:56:21 EDT
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 10:33:19 EDT
dmalloc has been removed in FC4.

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