|
From: Erik de C. L. <eri...@me...> - 2005-09-25 10:09:05
|
Hi all,
I'm getting this:
==11233== Address 0x52BFE690 is just below %esp. Possibly a bug in GCC/G++
==11233== v 2.96 or 3.0.X. To suppress, use: --workaround-gcc296-bugs=yes
I'm using gcc-4.0.1. Is this message stil relevant for this compiler?
Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo
+-----------------------------------------------------------+
"life is too long to be an expert at harmful things, including
such evilness as C++ and perl." -- Erik Naggum
|
|
From: Julian S. <js...@ac...> - 2005-09-25 10:21:39
|
On Sunday 25 September 2005 11:08, Erik de Castro Lopo wrote: > Hi all, > > I'm getting this: > > ==11233== Address 0x52BFE690 is just below %esp. Possibly a bug in > GCC/G++ ==11233== v 2.96 or 3.0.X. To suppress, use: > --workaround-gcc296-bugs=yes > > I'm using gcc-4.0.1. Is this message stil relevant for this compiler? Yes. Any access at all below %esp on an x86 is a unconditionally bug which could potentially crash your program. If you found such a thing and can pin it on gcc, then it's a gcc bug. Such things have happened at least twice before: gcc-2.96 (structure returns, a real dog) and in a gcc-3.0.0 prerelease (scheduling problem, it moved stack frame removal code around incorrectly). That said, I have not heard of any such problem in gcc 3.0.0 or later. J |
|
From: Erik de C. L. <eri...@me...> - 2005-09-25 13:30:10
|
Julian Seward wrote:
> Yes. Any access at all below %esp on an x86 is a unconditionally bug
> which could potentially crash your program. If you found such a
> thing and can pin it on gcc, then it's a gcc bug.
OK, I just recompiled the program with gcc-2.95 and the valgrind
error remains. I think that means that the problem is in my code.
The thing that confuses me is the line that valgrind is warning
about is:
retpcm [offset + j] = (buffer [j][pflac->bufferpos]) << shift ;
where all the arrays are on the heap, not the stack.
Anyone have any clues as to how to track this down? Should I look
at the assembler output?
Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo
+-----------------------------------------------------------+
"Unix and C are the ultimate computer viruses." -- Richard P Gabriel
|
|
From: Julian S. <js...@ac...> - 2005-09-25 17:13:34
|
> OK, I just recompiled the program with gcc-2.95 and the valgrind > error remains. I think that means that the problem is in my code. First of all, ensure you compile without optimisation. > The thing that confuses me is the line that valgrind is warning > about is: > > retpcm [offset + j] = (buffer [j][pflac->bufferpos]) << shift ; > > where all the arrays are on the heap, not the stack. Dunno. Worth adding some assertions to range checki the 3 array indices you're using. J |
|
From: Erik de C. L. <eri...@me...> - 2005-09-25 19:43:26
|
Julian Seward wrote: > First of all, ensure you compile without optimisation. Problem remains. > > The thing that confuses me is the line that valgrind is warning > > about is: > > > > retpcm [offset + j] = (buffer [j][pflac->bufferpos]) << shift ; > > > > where all the arrays are on the heap, not the stack. > > Dunno. Worth adding some assertions to range checki the 3 array indices > you're using. If I add the assertions, they don't get triggered. If I fiddle the range the assertion is checking to one less than the valid length it does get triggered. I guess I'll have to look at the assembler output. Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo +-----------------------------------------------------------+ Microsoft VISTA : Virus Infection Spyware Trojans and Adware! |
|
From: Erik de C. L. <eri...@me...> - 2005-09-25 20:19:07
|
Erik de Castro Lopo wrote: > If I add the assertions, they don't get triggered. If I fiddle the range > the assertion is checking to one less than the valid length it does get > triggered. Found my problem. The array length was not being initialised correctly. Valgrind is such a fantastically useful tool. Thanks! Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo +-----------------------------------------------------------+ "I'm too fucking busy, or vice versa" -- Dorothy Parker |
|
From: Paul P. <ppl...@gm...> - 2005-09-25 21:25:53
|
On 9/25/05, Erik de Castro Lopo <eri...@me...> wrote: > Found my problem. The array length was not being initialised correctly. But you said the arrays were on the heap ... Why did VG complain about stack? Something doesn't fit here. Perhaps you can provide a small test case demonstrating how a bug in (heap) array lenght shows up as a read beyond stack under VG? Cheers, |
|
From: Erik de C. L. <eri...@me...> - 2005-09-25 22:41:45
|
Paul Pluzhnikov wrote: > On 9/25/05, Erik de Castro Lopo <eri...@me...> wrote: > > > Found my problem. The array length was not being initialised correctly. > > But you said the arrays were on the heap ... I was wrong :-). The code in question was written by someone else and contributed to my project and it seemed to work. The only problem was that valgrind was reporting these errors. Looking at the code, pointers to the arrays were in a struct allocated on the heap. The struct was allocated using calloc() so the pointer values should have been NULL. AFAIAC the program should have crashed outside valgrind with a read/write to a NULL pointer. There was some code that allocated memory for these arrays that I had "#if 0"-ed out because I didn't understand why it was placed where it was. Removing the "#if 0" fixed the problem. > Why did VG complain about stack? Something doesn't fit here. How big is the window on the stack that valgrind checks? Does it check a long way below %esp or only a short way? > Perhaps you can provide a small test case demonstrating how a bug in > (heap) array lenght shows up as a read beyond stack under VG? I am still curious as to why the program was seemingly behaving correctly but was in hindsight so wrong. However, Since I have fixed my problem, my motivation for doing more debugging on this is not huge :-). If someone is interested in pursuing this I can provide the code and point them in the right direction. Teh first task would be parring down the example to a workable size; the code is about 40k lines and links to an external library. Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo +-----------------------------------------------------------+ "Data is not information, Information is not knowledge, Knowledge is not understanding, Understanding is not wisdom." -- Clifford Stoll |
|
From: Tom H. <to...@co...> - 2005-09-25 22:01:36
|
In message <2a2...@ma...>
Paul Pluzhnikov <ppl...@gm...> wrote:
> On 9/25/05, Erik de Castro Lopo <eri...@me...> wrote:
>
> > Found my problem. The array length was not being initialised correctly.
>
> But you said the arrays were on the heap ...
> Why did VG complain about stack? Something doesn't fit here.
Presumably one of the five variables used in the statement was on
the stack. Two of those variables may be arrays on the heap but the
pointer to the array and the index variables may well have been on
the stack.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Paul P. <ppl...@gm...> - 2005-09-25 22:14:23
|
On 9/25/05, Tom Hughes <to...@co...> wrote: >> Why did VG complain about stack? Something doesn't fit here. > Two of those variables may be arrays on the heap but the > pointer to the array and the index variables may well have been on > the stack. In which case they can't have triggered a "beyond stack" message, unless there is a gcc bug, which (given multiple gcc versions Erik tried) is unlikely. I *still* think something doesn't fit here. Cheers, |