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