This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: malloc patch for 2.2.4



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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]