[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: fopen/malloc MT bug
From: |
Wolfram Gloger |
Subject: |
Re: fopen/malloc MT bug |
Date: |
Thu, 19 Apr 2001 11:02:20 +0200 (MDT) |
Hello,
> My test don't say that. When I replace fopen() with anything(?) else, it
> works.
That is because fopen()/fclose() are internally calling
malloc()/free() on a chunk of memory. Without the fopen()/fclose(),
you are essentially just allocating memory in your original test.
_That_ may by chance work even with mcheck, as mcheck's internal lists
are only growing in that case.
> Besides, when I replaced all occurences of fopen() with open() in
> the real program, I got rid of clobbered memory (I don't use mcheck in
> this program). With fopen() the program was unstable.
That points to memory corruption in your program or to something like
a double fclose() on the same file. Please try running the program
with MALLOC_CHECK_=1 set in the environment.
> My tests say that mcheck makes no problems itself when multithreaded. I
> tried to run my large program (about 10 threads and Qt, intensive
> memory allocating) with mcheck and it went much farther than with
> fopen().
In my experience, GUI applications don't really stress test the
allocator with respect to multithreading. Your test program _with_
free()s (or rather delete[]) added would be a much better test. With
mcheck, that crashes almost instantly for me. Try it!
> Is there anyone who can authoritatively say
> or show that mcheck is not thread-safe() ?
You can believe Uli :-).
Regards,
Wolfram.