bug-glibc
[Top][All Lists]
Advanced

[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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]