What the heck is going on here? Compiler bug? (MS Support or anyone) 
Author Message
 What the heck is going on here? Compiler bug? (MS Support or anyone)

I am stepping though my code in debug.
At the end of a function I have a CleanUp: label before the function exits.
Note that this function doesn't return any value, also it is specified to
return an HRESULT.

HRESULT CoFCGenericFormHandler::_GetResponseTemplateRowsCount( IRowset*
pIRowset, ULONG* pulCount );

Problem #1: The compiler doesn't complain that the function doesn't return a
value.

When I step though this code, notice what happens at the end of the function
where the stack return/cleanup code should be.
I've included the disassembly below.  That's the most interesting stack
cleanup code I've ever seen! :-)
Obviously, it's difficult for Dorothy to return home here, and things go bad
fast when the code tries to free the pointer the second+ time.
In the body of the function I use goto to jump to the CleanUp: section in
the event of an error. It seems there is one matching jmp at the end of the
procedure for each instance of goto in the body... hmm. very weird!

1097: CleanUp:
1098:     if( cRowsObtained )
1000415E 83 7D B4 00          cmp         dword ptr [ebp-4Ch],0
10004162 74 23                je          CleanUp+29h (10004187)
1099:         pIRowset->ReleaseRows( cRowsObtained, rghRows, NULL, NULL,
NULL);
10004164 8B F4                mov         esi,esp
10004166 6A 00                push        0
10004168 6A 00                push        0
1000416A 6A 00                push        0
1000416C 8D 4D B0             lea         ecx,[ebp-50h]
1000416F 51                   push        ecx
10004170 8B 55 B4             mov         edx,dword ptr [ebp-4Ch]
10004173 52                   push        edx
10004174 8B 45 08             mov         eax,dword ptr [ebp+8]
10004177 8B 08                mov         ecx,dword ptr [eax]
10004179 8B 55 08             mov         edx,dword ptr [ebp+8]
1000417C 52                   push        edx
1000417D FF 51 18             call        dword ptr [ecx+18h]
10004180 3B F4                cmp         esi,esp
10004182 E8 19 F5 00 00       call        __chkesp (100136a0)
1100:
1101:     if( pRowData )
10004187 83 7D B8 00          cmp         dword ptr [ebp-48h],0
1000418B 74 0C                je          CleanUp+3Bh (10004199)
1102:         free( pRowData );
1000418D 8B 45 B8             mov         eax,dword ptr [ebp-48h]
10004190 50                   push        eax
10004191 E8 2A 08 01 00       call        free (100149c0)
10004196 83 C4 04             add         esp,4
1103:
1104: }
10004199 EB C3                jmp         CleanUp (1000415e)
1000419B EB C1                jmp         CleanUp (1000415e)
1000419D EB BF                jmp         CleanUp (1000415e)
1000419F EB BD                jmp         CleanUp (1000415e)
100041A1 EB BB                jmp         CleanUp (1000415e)
100041A3 EB B9                jmp         CleanUp (1000415e)



Wed, 01 Oct 2003 00:55:50 GMT  
 What the heck is going on here? Compiler bug? (MS Support or anyone)

Quote:

>I am stepping though my code in debug.
>At the end of a function I have a CleanUp: label before the function exits.
>Note that this function doesn't return any value, also it is specified to
>return an HRESULT.

>HRESULT CoFCGenericFormHandler::_GetResponseTemplateRowsCount( IRowset*
>pIRowset, ULONG* pulCount );

>Problem #1: The compiler doesn't complain that the function doesn't return a
>value.

>When I step though this code, notice what happens at the end of the function
>where the stack return/cleanup code should be.
>I've included the disassembly below.  That's the most interesting stack
>cleanup code I've ever seen! :-)
>Obviously, it's difficult for Dorothy to return home here, and things go bad
>fast when the code tries to free the pointer the second+ time.
>In the body of the function I use goto to jump to the CleanUp: section in
>the event of an error. It seems there is one matching jmp at the end of the
>procedure for each instance of goto in the body... hmm. very weird!

>1097: CleanUp:
>1098:     if( cRowsObtained )
>1000415E 83 7D B4 00          cmp         dword ptr [ebp-4Ch],0
>10004162 74 23                je          CleanUp+29h (10004187)
>1099:         pIRowset->ReleaseRows( cRowsObtained, rghRows, NULL, NULL,
>NULL);
>10004164 8B F4                mov         esi,esp
>10004166 6A 00                push        0
>10004168 6A 00                push        0
>1000416A 6A 00                push        0
>1000416C 8D 4D B0             lea         ecx,[ebp-50h]
>1000416F 51                   push        ecx
>10004170 8B 55 B4             mov         edx,dword ptr [ebp-4Ch]
>10004173 52                   push        edx
>10004174 8B 45 08             mov         eax,dword ptr [ebp+8]
>10004177 8B 08                mov         ecx,dword ptr [eax]
>10004179 8B 55 08             mov         edx,dword ptr [ebp+8]
>1000417C 52                   push        edx
>1000417D FF 51 18             call        dword ptr [ecx+18h]
>10004180 3B F4                cmp         esi,esp
>10004182 E8 19 F5 00 00       call        __chkesp (100136a0)
>1100:
>1101:     if( pRowData )
>10004187 83 7D B8 00          cmp         dword ptr [ebp-48h],0
>1000418B 74 0C                je          CleanUp+3Bh (10004199)
>1102:         free( pRowData );
>1000418D 8B 45 B8             mov         eax,dword ptr [ebp-48h]
>10004190 50                   push        eax
>10004191 E8 2A 08 01 00       call        free (100149c0)
>10004196 83 C4 04             add         esp,4
>1103:
>1104: }
>10004199 EB C3                jmp         CleanUp (1000415e)
>1000419B EB C1                jmp         CleanUp (1000415e)
>1000419D EB BF                jmp         CleanUp (1000415e)
>1000419F EB BD                jmp         CleanUp (1000415e)
>100041A1 EB BB                jmp         CleanUp (1000415e)
>100041A3 EB B9                jmp         CleanUp (1000415e)

Can you condense this to a short console program that demonstrates the
problem but doesn't rely on COM? If so, please post the source here
with compilation instructions. It looks like you might have found a
bug, but you need to make it easier for people to reproduce it.

--
Doug Harrison [VC++ MVP]
Eluent Software, LLC
http://www.eluent.com
Tools for Visual C++ and Windows



Thu, 02 Oct 2003 05:01:24 GMT  
 What the heck is going on here? Compiler bug? (MS Support or anyone)
Hi.  Here is a simple Win32 Console App which demonstrates the bug.
Simply create a simple Win32 Console project and use the below code for
main( ) and the DoGoto( ) function.
You will see that the code compiles correctly (it shouldn't) and then will
enter an infinite loop due to a jmp statement which is inserted at the end
of the procedure.

int DoGoto( bool bVal )
{
   if( bVal == true )
   {
       goto CleanUp;
   }
   else
      bVal = true;

CleanUp:
   bVal = false;

Quote:
}

int main(int argc, char* argv[])
{
    bool bTest = true;

    DoGoto( bTest );

    return 0;

Quote:
}

Here is the dissassembly of the instruction sequence generated for the end
of the DoGoto( ) function.
Note that this enters an infinite loop due to the jmp statement inserted at
the end of the procedure.
13:       else
14:           bVal = true;
00401047 C6 45 08 01          mov         byte ptr [ebp+8],1
15:
16:   CleanUp:
17:       bVal = false;
0040104B C6 45 08 00         mov         byte ptr [ebp+8],0
18:   }
0040104F EB FA                  jmp         CleanUp (0040104b)

Here is the dissassembly view from a modified DoGoto( ) function which
correctly returns the int as the function specifies.
Note that the compiler doesn't remove the jmp statement which was the source
of the previous problem, instead it inserts
an additional jmp statement to jump past it, thus circumventing the infinite
loop! Hmm...

0040104B C6 45 08 00           mov         byte ptr [ebp+8],0
18:       return 1;
0040104F B8 01 00 00 00      mov         eax,1
00401054 EB 02                     jmp         CleanUp+0Dh (00401058)
19:   }
00401056 EB F3                    jmp         CleanUp (0040104b)
00401058 5F                          pop         edi

I did notice a reference to this same problem in a reader's letter in the
March 2001 issue of Windows Developer's Journal.

~ Colin Reinhardt

System Architect
www.transenda.com



Quote:

> >I am stepping though my code in debug.
> >At the end of a function I have a CleanUp: label before the function
exits.
> >Note that this function doesn't return any value, also it is specified to
> >return an HRESULT.

> >HRESULT CoFCGenericFormHandler::_GetResponseTemplateRowsCount( IRowset*
> >pIRowset, ULONG* pulCount );

> >Problem #1: The compiler doesn't complain that the function doesn't
return a
> >value.

> >When I step though this code, notice what happens at the end of the
function
> >where the stack return/cleanup code should be.
> >I've included the disassembly below.  That's the most interesting stack
> >cleanup code I've ever seen! :-)
> >Obviously, it's difficult for Dorothy to return home here, and things go
bad
> >fast when the code tries to free the pointer the second+ time.
> >In the body of the function I use goto to jump to the CleanUp: section in
> >the event of an error. It seems there is one matching jmp at the end of
the
> >procedure for each instance of goto in the body... hmm. very weird!

> >1097: CleanUp:
> >1098:     if( cRowsObtained )
> >1000415E 83 7D B4 00          cmp         dword ptr [ebp-4Ch],0
> >10004162 74 23                je          CleanUp+29h (10004187)
> >1099:         pIRowset->ReleaseRows( cRowsObtained, rghRows, NULL, NULL,
> >NULL);
> >10004164 8B F4                mov         esi,esp
> >10004166 6A 00                push        0
> >10004168 6A 00                push        0
> >1000416A 6A 00                push        0
> >1000416C 8D 4D B0             lea         ecx,[ebp-50h]
> >1000416F 51                   push        ecx
> >10004170 8B 55 B4             mov         edx,dword ptr [ebp-4Ch]
> >10004173 52                   push        edx
> >10004174 8B 45 08             mov         eax,dword ptr [ebp+8]
> >10004177 8B 08                mov         ecx,dword ptr [eax]
> >10004179 8B 55 08             mov         edx,dword ptr [ebp+8]
> >1000417C 52                   push        edx
> >1000417D FF 51 18             call        dword ptr [ecx+18h]
> >10004180 3B F4                cmp         esi,esp
> >10004182 E8 19 F5 00 00       call        __chkesp (100136a0)
> >1100:
> >1101:     if( pRowData )
> >10004187 83 7D B8 00          cmp         dword ptr [ebp-48h],0
> >1000418B 74 0C                je          CleanUp+3Bh (10004199)
> >1102:         free( pRowData );
> >1000418D 8B 45 B8             mov         eax,dword ptr [ebp-48h]
> >10004190 50                   push        eax
> >10004191 E8 2A 08 01 00       call        free (100149c0)
> >10004196 83 C4 04             add         esp,4
> >1103:
> >1104: }
> >10004199 EB C3                jmp         CleanUp (1000415e)
> >1000419B EB C1                jmp         CleanUp (1000415e)
> >1000419D EB BF                jmp         CleanUp (1000415e)
> >1000419F EB BD                jmp         CleanUp (1000415e)
> >100041A1 EB BB                jmp         CleanUp (1000415e)
> >100041A3 EB B9                jmp         CleanUp (1000415e)

> Can you condense this to a short console program that demonstrates the
> problem but doesn't rely on COM? If so, please post the source here
> with compilation instructions. It looks like you might have found a
> bug, but you need to make it easier for people to reproduce it.

> --
> Doug Harrison [VC++ MVP]
> Eluent Software, LLC
> http://www.eluent.com
> Tools for Visual C++ and Windows



Sat, 04 Oct 2003 03:18:23 GMT  
 What the heck is going on here? Compiler bug? (MS Support or anyone)
Hi.  Here is a simple Win32 Console App which demonstrates the bug.
Simply create a simple Win32 Console project and use the below code for
main( ) and the DoGoto( ) function.
You will see that the code compiles correctly (it shouldn't) and then will
enter an infinite loop due to a jmp statement which is inserted at the end
of the procedure.

int DoGoto( bool bVal )
{
   if( bVal == true )
   {
       goto CleanUp;
   }
   else
      bVal = true;

CleanUp:
   bVal = false;

Quote:
}

int main(int argc, char* argv[])
{
    bool bTest = true;

    DoGoto( bTest );

    return 0;

Quote:
}

Here is the dissassembly of the instruction sequence generated for the end
of the DoGoto( ) function.
Note that this enters an infinite loop due to the jmp statement inserted at
the end of the procedure.
13:       else
14:           bVal = true;
00401047 C6 45 08 01          mov         byte ptr [ebp+8],1
15:
16:   CleanUp:
17:       bVal = false;
0040104B C6 45 08 00         mov         byte ptr [ebp+8],0
18:   }
0040104F EB FA                  jmp         CleanUp (0040104b)

Here is the dissassembly view from a modified DoGoto( ) function which
correctly returns the int as the function specifies.
Note that the compiler doesn't remove the jmp statement which was the source
of the previous problem, instead it inserts
an additional jmp statement to jump past it, thus circumventing the infinite
loop! Hmm...

0040104B C6 45 08 00           mov         byte ptr [ebp+8],0
18:       return 1;
0040104F B8 01 00 00 00      mov         eax,1
00401054 EB 02                     jmp         CleanUp+0Dh (00401058)
19:   }
00401056 EB F3                    jmp         CleanUp (0040104b)
00401058 5F                          pop         edi

I did notice a reference to this same problem in a reader's letter in the
March 2001 issue of Windows Developer's Journal.

~ Colin Reinhardt

System Architect
www.transenda.com



Quote:

> >I am stepping though my code in debug.
> >At the end of a function I have a CleanUp: label before the function
exits.
> >Note that this function doesn't return any value, also it is specified to
> >return an HRESULT.

> >HRESULT CoFCGenericFormHandler::_GetResponseTemplateRowsCount( IRowset*
> >pIRowset, ULONG* pulCount );

> >Problem #1: The compiler doesn't complain that the function doesn't
return a
> >value.

> >When I step though this code, notice what happens at the end of the
function
> >where the stack return/cleanup code should be.
> >I've included the disassembly below.  That's the most interesting stack
> >cleanup code I've ever seen! :-)
> >Obviously, it's difficult for Dorothy to return home here, and things go
bad
> >fast when the code tries to free the pointer the second+ time.
> >In the body of the function I use goto to jump to the CleanUp: section in
> >the event of an error. It seems there is one matching jmp at the end of
the
> >procedure for each instance of goto in the body... hmm. very weird!

> >1097: CleanUp:
> >1098:     if( cRowsObtained )
> >1000415E 83 7D B4 00          cmp         dword ptr [ebp-4Ch],0
> >10004162 74 23                je          CleanUp+29h (10004187)
> >1099:         pIRowset->ReleaseRows( cRowsObtained, rghRows, NULL, NULL,
> >NULL);
> >10004164 8B F4                mov         esi,esp
> >10004166 6A 00                push        0
> >10004168 6A 00                push        0
> >1000416A 6A 00                push        0
> >1000416C 8D 4D B0             lea         ecx,[ebp-50h]
> >1000416F 51                   push        ecx
> >10004170 8B 55 B4             mov         edx,dword ptr [ebp-4Ch]
> >10004173 52                   push        edx
> >10004174 8B 45 08             mov         eax,dword ptr [ebp+8]
> >10004177 8B 08                mov         ecx,dword ptr [eax]
> >10004179 8B 55 08             mov         edx,dword ptr [ebp+8]
> >1000417C 52                   push        edx
> >1000417D FF 51 18             call        dword ptr [ecx+18h]
> >10004180 3B F4                cmp         esi,esp
> >10004182 E8 19 F5 00 00       call        __chkesp (100136a0)
> >1100:
> >1101:     if( pRowData )
> >10004187 83 7D B8 00          cmp         dword ptr [ebp-48h],0
> >1000418B 74 0C                je          CleanUp+3Bh (10004199)
> >1102:         free( pRowData );
> >1000418D 8B 45 B8             mov         eax,dword ptr [ebp-48h]
> >10004190 50                   push        eax
> >10004191 E8 2A 08 01 00       call        free (100149c0)
> >10004196 83 C4 04             add         esp,4
> >1103:
> >1104: }
> >10004199 EB C3                jmp         CleanUp (1000415e)
> >1000419B EB C1                jmp         CleanUp (1000415e)
> >1000419D EB BF                jmp         CleanUp (1000415e)
> >1000419F EB BD                jmp         CleanUp (1000415e)
> >100041A1 EB BB                jmp         CleanUp (1000415e)
> >100041A3 EB B9                jmp         CleanUp (1000415e)

> Can you condense this to a short console program that demonstrates the
> problem but doesn't rely on COM? If so, please post the source here
> with compilation instructions. It looks like you might have found a
> bug, but you need to make it easier for people to reproduce it.

> --
> Doug Harrison [VC++ MVP]
> Eluent Software, LLC
> http://www.eluent.com
> Tools for Visual C++ and Windows



Sat, 04 Oct 2003 03:17:10 GMT  
 What the heck is going on here? Compiler bug? (MS Support or anyone)

Quote:
> Hi.  Here is a simple Win32 Console App which demonstrates the bug.
> Simply create a simple Win32 Console project and use the below code for
> main( ) and the DoGoto( ) function.
> You will see that the code compiles correctly (it shouldn't) and then will
> enter an infinite loop due to a jmp statement which is inserted at the end
> of the procedure.

> int DoGoto( bool bVal )
> {
>    if( bVal == true )
>    {
>        goto CleanUp;
>    }
>    else
>       bVal = true;

> CleanUp:
>    bVal = false;
> }

> int main(int argc, char* argv[])
> {
>     bool bTest = true;

>     DoGoto( bTest );

>     return 0;
> }

Fascinating - looks like a compiler bug to me. But actually the code should
produce a diagnostic when compiled as you are not returning an int from
DoGoto. If you modify your code to either:

- make DoGoto have a void return type

or

- add a "return 1;" statement at the end of DoGoto

then it works fine!

NeilB



Sat, 04 Oct 2003 03:01:56 GMT  
 
 [ 5 post ] 

 Relevant Pages 

1. What the heck is going on here? Compiler bug? (MS Support or anyone)

2. What the heck am I doing wrong??

3. what the heck am i doing wrong....?

4. Why am I getting this error - compiler bug?

5. Template Turmoil -- what the heck is going on?!

6. What the heck is going on?

7. MS compiler support for XScale processor for PocketPC 2002

8. Anyone noticed this bug in the compiler?

9. MS C Compiler bug

10. Compiler Template Bug (MS people please read)

11. Holy shi* MS fixed a compiler bug!

12. I am going to study "C"

 

 
Powered by phpBB® Forum Software