Bug 88561 - use of mtrace causes internal memory errors
Summary: use of mtrace causes internal memory errors
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: glibc
Version: 9
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2003-04-10 21:55 UTC by John Reiser
Modified: 2016-11-24 14:57 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Last Closed: 2004-08-26 04:24:35 UTC

Attachments (Terms of Use)

Description John Reiser 2003-04-10 21:55:39 UTC
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):

How reproducible:

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

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 18:51:18 UTC
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 04:24:35 UTC
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.