malloc patch for 2.2.4
Christian Iseli
chris@ludwig-alpha.unil.ch
Wed Aug 29 13:51:00 GMT 2001
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
More information about the Libc-alpha
mailing list