This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: malloc patch for 2.2.4
- To: Jakub Jelinek <jakub at redhat dot com>
- Subject: Re: malloc patch for 2.2.4
- From: Christian Iseli <chris at ludwig-alpha dot unil dot ch>
- Date: Wed, 29 Aug 2001 22:48:09 +0200
- cc: Wolfram Gloger <Wolfram dot Gloger at dent dot med dot uni-muenchen dot de>, geoffk at redhat dot com, libc-alpha at sources dot redhat dot com
jakub@redhat.com said:
> I'd suggest using ElectricFence, MALLOC_CHECK_ or some similar memory
> allocation checker.
Thanks for the suggestions. I just completed some tests using MALLOC_CHECK_.
If I run in single thread mode (switch -a 1), I get no messages:
$ MALLOC_CHECK_=1 /usr/src/redhat/BUILD/ncbi/build/megablast
-d "est_hum-re est_hum-up" -i chrom21_f.seq -f T -J F -F F -W 48
-a 1 >chrom21_ESTs </dev/null
malloc: using debugging hooks
Now, if I run in multi-threaded mode(switch -a 2), I get a few messages:
$ MALLOC_CHECK_=1 /usr/src/redhat/BUILD/ncbi/build/megablast
-d "est_hum-re est_hum-up" -i chrom21_f.seq -f T -J F -F F -W 48
-a 2 >chrom21_ESTs </dev/null
malloc: using debugging hooks
free(): invalid pointer 0x9630bc0!
free(): invalid pointer 0x8847158!
free(): invalid pointer 0x8765018!
free(): invalid pointer 0x8a6cbb0!
free(): invalid pointer 0x8b3f1f0!
free(): invalid pointer 0x9a1fd78!
The darndest thing is that in both cases the program completes successfuly,
and produces the correct results... The SegV doesn't occur in this case.
BTW, I forgot to mention this is all on a Dell PowerEdge dual PIII machine.
In case it matters, I had a look to top's output while the program was
running. Shortly after starting, the memory usage grows to ~320 MB (the
machine has 1GB RAM), then slowly increases to over 400 MB. Then memory usage
drops back to around 330 MB, then slowly increases again. The cycle is
repeated numerous times, until completion.
Does this make any sense ?
Regards,
Christian