Red Hat Bugzilla – Bug 88561
use of mtrace causes internal memory errors
Last modified: 2007-04-18 12:52:56 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:
This is the consequence of the cleanup handlers running in no specific order or having priorities. It's unlikely to be changed.
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.