Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > GCC 4.4.0 produce crashing code in release mode

Reply
Thread Tools

GCC 4.4.0 produce crashing code in release mode

 
 
Qi
Guest
Posts: n/a
 
      03-30-2011
After another two hours work, now I'm 99% sure it's a bug in gcc
4.4.0 when optimizing for function with "stdcall" calling convention.

Below is a piece of disassemble code (dump from OllyDbg, I don't
know how to use Code::Blocks to debug efficiently).

004067EA > CC int3
004067EB . C74424 78 CF07>mov [dword ss:esp+78],7CF
004067F3 . 8B4C24 28 mov ecx,[dword ss:esp+28]
004067F7 . C641 08 00 mov [byte ds:ecx+8],0
004067FB . 8B39 mov edi,[dword ds:ecx]
004067FD . 897C24 2C mov [dword ss:esp+2C],edi
00406801 . 89F8 mov eax,edi
00406803 . 39F9 cmp ecx,edi
00406805 . 0F84 5B010000 je RunTestC.00406966
0040680B . 8D4424 48 lea eax,[dword ss:esp+48]
0040680F . 894424 1C mov [dword ss:esp+1C],eax
00406813 . 90 nop
00406814 > 8B5424 2C mov edx,[dword ss:esp+2C]
00406818 . 8B42 08 mov eax,[dword ds:edx+8]
0040681B . 85C0 test eax,eax
0040681D . 74 10 je short RunTestC.0040682F
0040681F . 8B10 mov edx,[dword ds:eax]
00406821 . 8D4C24 78 lea ecx,[dword ss:esp+78]
00406825 . 894C24 04 mov [dword ss:esp+4],ecx
00406829 . 890424 mov [dword ss:esp],eax
0040682C . FF52 10 call [dword ds:edx+10]
0040682F > 8B7C24 2C mov edi,[dword ss:esp+2C]
00406833 . 8B47 18 mov eax,[dword ds:edi+18]

Note the call at address 0040682C, it's a call to a member function,
void __stdcall callback1(int n) const {
(void)n;
TS_TRACE("callback1");
}

And note that in the end of callback1, there is a ret instruction
which is "retn 8", which is a normal return instruction for stdcall.
However, the problem is, among all of the above disassemble code,
there is no any normal "push" instruction to pass the arguments.
Instead of that, the compiler uses existing stack frame to pass the
argument, see address 004067EB, 7CF is the argument 1999 I passed
to the callback1.

As as stdcall, after the call, at the address 0040682F, ESP should
be same as at the address 00406829 so the stack is balanced.
But due to the "retn 8" I mentioned above, the stack gets unbalanced
and then at address 0040682F EDI gets wrong value.

I also examined GCC 4.5.2, the code of callback1 it generated, the last
return instruction is "retn", as if it's not a stdcall, so there is
no problem (of course other code is also different with 4.4.0).

Since this bug had been fixed in newer GCC, we can ignore this bug.
But I'm happy to spend two "two hours" to learn and verify that,
1, My code is safe and has no the potential nasty bugs I suspected,
2, Learn a little bit how C++ compilers optimize the code (the
disassemble code is too hard to read).

I think I should read the release notes of past GCC versions when
I have another two hours.



--
WQ
 
Reply With Quote
 
 
 
 
Jorgen Grahn
Guest
Posts: n/a
 
      03-30-2011
On Wed, 2011-03-30, Qi wrote:
> On 2011-3-29 22:52, Kai-Uwe Bux wrote:
>
>> Hunting for undefined behavior is difficult. You probably had a look at the
>> crash in a debugger and worked your way up the call stack leading to the
>> crash. Another thing, I would try, is to search for errors using tools such
>> as valgrind.

>
> valgrind looks good. But it has no Windows version (why?).


Valgrind is delicate software. It seems to be a lot of work to port it
even from Linux to some other Unix, or from x86 to some other CPU
architecture.

I'm not sure what is available and inexpensive on Windows.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
 
Reply With Quote
 
 
 
 
jacob navia
Guest
Posts: n/a
 
      04-03-2011
Le 29/03/11 16:32, werasm a écrit :
> On Mar 29, 4:19 pm, Qi<(E-Mail Removed)> wrote:
>
>
>> Can it be a bug in GCC 4.4.0?
>> I'm quite worrying that if it's a potential bug in my code.

>
> More than likely a bug in your code...
>
>> However, I can't post any code piece here because the code
>> is a little bit complicated and I don't know where causes
>> the crash.

>
> How many lines? Then we can't help you.
>
>> I spent two hours on trying to see what's wrong in my code
>> but got no result.

>
> Only two hours?
>
>> Is there any famous known bug that will produce wrong code
>> in GCC 4.4.0?

>
> I'd rather trust GCC 4.4.0 than your code, no offence meant.
>
> Regards,
>
> Werner
>


It was a bug in GCC.

I have been bitten by so many that your blind trust in that software
looks ridiculous. No offense meant.




 
Reply With Quote
 
Virchanza
Guest
Posts: n/a
 
      04-04-2011
On Mar 29, 3:26*pm, Qi <(E-Mail Removed)> wrote:
> Forgot to say, the crashing only happens if optimization is enabled
> (-O2 or -O3). If no optimization, it won't crash.



I've experienced this before, i.e. my program worked fine until I did -
O3.

I'm willing to bet you have a sequence point violation somewhere in
your code.

My own problem was caused by the following function:

void StrToLower(char *p)
{
while ( *p++ = tolower( (char unsigned)*p ) );
}

 
Reply With Quote
 
Joshua Maurice
Guest
Posts: n/a
 
      04-04-2011
On Apr 3, 3:01*pm, jacob navia <(E-Mail Removed)> wrote:
> It was a bug in GCC.
>
> I have been bitten by so many that your blind trust in that software
> looks ridiculous. No offense meant.


I'm curious. Can you link to the bug report, or give a short
description of it?
 
Reply With Quote
 
jacob navia
Guest
Posts: n/a
 
      04-04-2011
Le 04/04/11 09:45, Joshua Maurice a écrit :
> On Apr 3, 3:01 pm, jacob navia<(E-Mail Removed)> wrote:
>> It was a bug in GCC.
>>
>> I have been bitten by so many that your blind trust in that software
>> looks ridiculous. No offense meant.

>
> I'm curious. Can you link to the bug report, or give a short
> description of it?

I don't report errors to them anymore.
Last time I did it (it was an error in gdb) I send them a fix.

There was no answer, the bug is still there, 2 years later.

Maybe they did not want to fix it, or they did not care. In any case
I just do some work around or try to use another compiler that is
a better compiler, like Intel's.

If you want to know about gcc's bugs go to their site and look at
the "open bugs" page.

There, you will find those that were reported.

 
Reply With Quote
 
Miles Bader
Guest
Posts: n/a
 
      04-06-2011
jacob navia <(E-Mail Removed)> writes:
> It was a bug in GCC.


Er, the OP (Qi) gave no example, and indeed, no information about what
his problem is. How on earth do you know "it was a bug in GCC"?!

GCC, like every compiler, has bugs, but it's a fairly solid compiler,
and it's far, far, more common for crashes to be caused by problems with
user code. So absent any actual information, it's much more likely that
werasm is correct than you are...

-miles

--
Resign, v. A good thing to do when you are going to be kicked out.
 
Reply With Quote
 
Jorgen Grahn
Guest
Posts: n/a
 
      04-06-2011
On Wed, 2011-04-06, Miles Bader wrote:
> jacob navia <(E-Mail Removed)> writes:
>> It was a bug in GCC.

>
> Er, the OP (Qi) gave no example, and indeed, no information about what
> his problem is. How on earth do you know "it was a bug in GCC"?!


The OP wrote about it somewhere in the thread, and it sounded
trustworthy ... even though he didn't enable us to repeat his results.

> GCC, like every compiler, has bugs, but it's a fairly solid compiler,
> and it's far, far, more common for crashes to be caused by problems with
> user code. So absent any actual information, it's much more likely that
> werasm is correct than you are...


IIRC, it turned out the OP used MinGW or whatever that Windows port is
called, and some Windows-specific(?) extension called "stdcall".

A compiler bug suddenly sounds less unlikely!

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
 
Reply With Quote
 
Qi
Guest
Posts: n/a
 
      04-07-2011
On 2011-4-6 23:55, Jorgen Grahn wrote:
>
> The OP wrote about it somewhere in the thread, and it sounded
> trustworthy ... even though he didn't enable us to repeat his results.


Yes.
And indeed the source code is on my personal site as open source.
But it makes no sense if I post the link here then some persons
start *wasting* time on compiling and trying to reproduce the bug.

It's meaningless because now I'm convinced that my code is fine
and 99% sure it's a bug in gcc, so no wasting time any more.

It's also meaningless to verify it's a bug in gcc 4.4.0. The bug
at least had been fixed in later gcc.

And thanks for your trust.

>> GCC, like every compiler, has bugs, but it's a fairly solid compiler,
>> and it's far, far, more common for crashes to be caused by problems with
>> user code. So absent any actual information, it's much more likely that
>> werasm is correct than you are...

>
> IIRC, it turned out the OP used MinGW or whatever that Windows port is
> called, and some Windows-specific(?) extension called "stdcall".
>
> A compiler bug suddenly sounds less unlikely!


Yes again.
I disassemblied the binary and found the problematical code.
That's why I can say 99% sure.

An off topic note is that stdcall should work mostly fine in MinGW because
so many applications are developed with MinGW/Qt. Seems the bug only occurs
under some complicated environment.


--
WQ

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
User Control access fails in debug mode, works in release mode rbg ASP .Net 0 01-17-2007 10:51 PM
can java produce .exe? if it can produce jar,how do you do? aungkopyay@gmail.com Java 5 10-27-2006 02:07 AM
option in gcc that lets us produce object code for 16-bit processor chandanlinster C Programming 10 07-24-2006 02:59 AM
Response.Redirect is slooow in debug mode, ok in release mode =?Utf-8?B?TWF4?= ASP .Net 0 02-11-2006 12:37 AM
Debug mode dll's vs release mode dll's? Dave ASP .Net 0 02-20-2004 03:49 AM



Advertisments