Bug 88561 - use of mtrace causes internal memory errors
use of mtrace causes internal memory errors
Status: CLOSED UPSTREAM
Product: Red Hat Linux
Classification: Retired
Component: glibc (Show other bugs)
9
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-04-10 17:55 EDT by John Reiser
Modified: 2007-04-18 12:52 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-08-26 00:24:35 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description John Reiser 2003-04-10 17:55:39 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529

Description of problem:
After fixing bug 88056, but running the same testcase libio/tst-fopenloc with
the shell environment variable MALLOC_TRACE=<filename> , a similar error to bug
88056 occurs.  A block is free()d, but referenced later to decide if it should
be free()d again.

[gconv_db.c:199] (Thread 0) **READ_DANGLING**
>>   if (--step->__counter == 0)

  Reading from a dangling pointer.

  Pointer : 0x080a7e68
  In block: 0x080a7e60 thru 0x080a7e9b (60 bytes)
                  block allocated at gconv_db.c, 231
                       gen_steps()  gconv_db.c, 231
                 find_derivation()  gconv_db.c, 622
          __gconv_find_transform()  gconv_db.c, 723
                 __wcsmbs_getfct()  wcsmbsload.c, 92
              __wcsmbs_load_conv()  wcsmbsload.c, 209
             __wcsmbs_clone_conv()  wcsmbsload.h, 76
                       _IO_fwide()  iofwide.c, 137
                          fputws()  iofputws.c, 41
                            main()  tst-fopenloc.c, 56

stack trace where memory was freed:
                 free_derivation()  gconv_db.c, 189
                tdestroy_recurse()  tsearch.c, 642
                tdestroy_recurse()  tsearch.c, 639
                      __tdestroy()  tsearch.c, 639
                        free_mem()  gconv_db.c, 797
             __GI___libc_freeres()  set-freeres.c, 49
                release_libc_mem()  mtrace.c, 247
                       __GI_exit()  exit.c, 54
            libc.so.6 0x401db708()
                          _start()  ../sysdeps/i386/elf/start.S, 81

  Stack trace where the error occurred:
            __gconv_release_step()  gconv_db.c, 199
         __gconv_close_transform()  gconv_db.c, 752
               _nl_cleanup_ctype()  wcsmbsload.c, 265
               _nl_unload_locale()  loadlocale.c, 257
                        free_mem()  setlocale.c, 466
             __GI___libc_freeres()  set-freeres.c, 49
                release_libc_mem()  mtrace.c, 247
                       __GI_exit()  exit.c, 54
            libc.so.6 0x401db708()
                          _start()  ../sysdeps/i386/elf/start.S, 81



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

How reproducible:
Always

Steps to Reproduce:
1.Run testcase libio/tst-fopenloc with environment variable
MALLOC_TRACE=<filename> .
2.Observe all malloc()[/calloc()/realloc()] and free().
3.
    

Actual Results:  A block is free()d, but later referenced to decide whether to
free() it again.

Expected Results:  No further reference to a block that has been free()d.

Additional info:
Comment 1 Ulrich Drepper 2003-04-17 14:51:18 EDT
This is the consequence of the cleanup handlers running in no specific order or
having priorities.  It's unlikely to be changed.
Comment 2 Ulrich Drepper 2004-08-26 00:24:35 EDT
This should actually be handled correctly in the upstream version and
in the FC3 version.  I'm closing this bug now.  In case it is still
reproducable, reopen.

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