[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mingw-users
Subject:    Re: [Mingw-users] Apparent compiler bug causing code crash
From:       Keith Marshall <keithmarshall () users ! sourceforge ! net>
Date:       2013-12-31 10:34:42
Message-ID: 52C29DC2.4010203 () users ! sourceforge ! net
[Download RAW message or body]

On 30/12/13 01:26, curt wrote:
> Just ported some libraries of mine to a new project and one of the 
> well-used one choked and died. After some sluthing I found the problem 
> appears to be thing mingw linker getting confused on what to call.

This is an incorrect conclusion, I think; your issue, on the basis of
the evidence you provide here, has nothing whatsoever to do with the
linker being confused, (or doing anything untoward).

> Simplified example:

Which isn't even compilable ... but after fixing it

> #include <stdio.h>
> #include <stdarg.h>
> 
> void polyCrash( const char* format, ... )
> {
> va_list arg;
> va_start( arg, format );
> char buf[80];
> vsnprintf( buf, 80, format, arg );
> va_end( arg );
> }
> 
> void polyCrash( const char* format, va_list arg )
> {
> char buf[80];
> vsnprintf( buf, 80, format, arg );
> }
> 
> int main( int argc,char *argv[] )
> {

such that this invalid (incomplete) statement

> polyCrash( "%s", (char *)"crash"

becomes

  polyCrash( "%s", (char *)"crash" );

and also adding

  return 0;

to make the function pedantically complete

> }
> 
> compile with a simple: gcc -o t test.cpp

and instead, compiling with

  mingw32-g++ -S test.cpp

(I'm using a Linux hosted cross compiler; hence the mingw32- prefix),
inspection of the generated assembly code indicates:

1) Your void "polyCrash( const char *, ... );" form of the overridden
function is given a C++ mangled name of "__Z9polyCrashPKcz"

2) The "void polyCrash( const char *, va_list );" alternative is given
the mangled name "__Z9polyCrashPKcPc".

For reference, each of these mangled names is consistently reproduced by
both G++-3.4.5 and G++-4.8.1 cross compiler variants, and also by a
G++-4.7.2 native variant running on a Win7 VM; the corresponding names
generated by the native G++-4.7.3 compiler, on the Linux host itself,
are "_Z9polyCrashPKcz" and "_Z9polyCrashPKcP13__va_list_tag" respectively.

A visual analysis of those mangled names may hint at the problem, but
before going on to discuss it, I feel obliged to point out that your
function overrides are ambiguous by design; this should probably be
considered an extremely ill advised coding choice on your part, since
the variant argument form will always represent a viable candidate to
match any call to the va_list form.

That said, the "__Z9polyCrashPKcPc" name, as generated by the mingw32
targetting variants of G++, does seem to be wrong, as confirmed by

  $ mingw32-c++filt __Z9polyCrashPKcPc
  polyCrash(char const*, char*)

This represents a function signature which does not match your source

  void polyCrash( const char *format, va_list arg )

(a va_list is *not* a char*, yet this is how mingw32-g++ has compiled
it); however, it does *exactly* match your usage in

  polyCrash( "%s", (char *)"crash" );

Hence, this exact match results in the *compiler*, (not the linker),
choosing to call the va_list form of your polyCrash() function, when it
compiles this statement in main(); since this function expects an
*indirect* pointer reference, where it has been given a *direct* pointer
reference, your program crashes with a segmentation fault, due to the
dereference of an invalid pointer.

You may wish to file a bug report at http://gcc.gnu.org/bugzilla/ in
respect of the inappropriately generated C++ name mangling for va_list
arguments, in mingw32 builds of G++.  However, since this has been a
consistent feature of all three versions I've checked, and therefore
probably significantly more (perhaps even all) previous versions, you
should also seriously consider eliminating the potentially ambiguous
(and hence confusing) variant argument forms of function overrides,
(where the variant form may match one or more other override forms),
from your own source code.

-- 
Regards,
Keith.

------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
MinGW-users mailing list
MinGW-users@lists.sourceforge.net

This list observes the Etiquette found at 
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may \
cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:mingw-users-request@lists.sourceforge.net?subject=unsubscribe


[prev in list] [next in list] [prev in thread] [next in thread]