[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: gcc 3.2.2
- From: Christian Vogler <Christian.Vogler@...>
- Date: Tue, 2 Dec 2003 13:07:40 -0500
> This is unlikely. Running the same test under valgrind doesn't show the
> problem. My understanding of valgrind is that since it's completely
> transparent as far as user address space goes, it should have exactly the
> same (user-space) memory allocation patterns as running natively, so
> should show the same bugs.
The thing is that if the problem does not occur with Valgrind, it reveals that
there is a crucial difference. I do not know what it might be, but I'd
explicitly check that the memory allocation patterns are the same before
rejecting the possibility of a lua bug. That includes the memory allocation
patterns of the shared libraries that lua is linked against - what if, for
instance, lua were to corrupt data that belongs to glibc? As far as I know,
valgrind would not catch those cases. Unlikely, I agree, but the evidence
does not rule it out yet.
When we were chasing down the bugs in the dynamic linker in glibc, all of
these problems were reproducible with Valgrind, and actually confirmed that
the bug was in glibc. Something is very strange here. Out of curiosity, what
are the compiler flags and test scripts that you use to reproduce the bug?