2009/3/9 Wolfgang Glas <wolfgang.g...@ev-i.at>:
> Hi all,
>
>  I've now established to compile all of my source code for a mid-sized
> production C++ Windows Service using mingw-w64-20090307 and 
> mingw-w32-20090307.
>
>  All of this code is running stable with mingw32's gcc-3.4.5 version. (The
> service is a multithreaded CORBA servant using omniORB-4.1 and runs for weeks
> w/o memory leak or crashes...) The code has also undergone intensive valgrind
> testing under Linux.
>
>  Nevertheless I'm getting various crashes in my application, which I'm unable
> to reproduce in a test case:
>
> - The 32bit executable seems to work on Windows XP x86 without flaws.
>
> - The 32bit executable crashes in CosNaming::NamingContext::_narrow() insode
> omniORB413_nt.dll when started under Windows XP x64.
>
> - The 64bit executable crashes when alloca() is called. If the use of alloca()
> is pmitted, it crashes lateron.
>
> The stack traces of gdb are definitely unusable, but I got the impression that
> the programs are crashing. However, when I registers Microsoft's windbg tools 
> as
> the default post-mortem debugger, I get no popup from windbg nor a dump file 
> on
> disk...
>
> At this point I'm completely stuck. I have to wait until Linux rules the world
> or until MSVC has turned into a reasonable C compiler :(
>
> (Gosh, how old will I be when one of these happens...)
>
> Are there any ideas/hints on how to sort out these problems?
>
> Might it be possible, that the stack layout of mingw-w{32,64} does not conform
> to any subtle detail of the specification?
I don't assume that the stack layout itself is the problem.

> Might the fact, that the 32bit executable crashes under x64 be a hint, that 
> the
> calling conventions confuse the ntdll.dll calls? (ntdll.dll is AFAIK the only
> DLL, which has been replaced for WOW64 in order to dispatch kernel calls of
> 32bit apps to the 64bit kernel...)

Well, for 32-bit we use the same calling convention (and
implementation) as mingw32.
So I assume we have an optimization issue here in gcc. My guess is
that gimplifier, SSA, or IRA are making here troubles. Because, if you
compile your code without optimizations I bet, that your application
will work proper for mingw-w64's 64-bit and 32-bit version.

So I assume we have to take care about finding optimization problems here.
So to figure out more closely what's going wrong, we need regular
testsuite runs for 64-bits and 32-bits variant. So we have a better
chance to figure out, where the problems are.

Cheers,
Kai

-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination

------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Reply via email to