Windows7 STATUS_ACCESS_VIOLATION and gcc/g++ linking problems

[Tomas Staig]

Dear all,

we have successfully ported an application framework (based on CORBA) to 
Windows using Cygwin last year. This porting works properly under 
Windows XP, but we ran into some problems when we tried to use it under 
Windows 7 (32-bits) not long ago.

While compiling ACE/TAO (Initial parts of the compilation work ok), at 
some point it tries to execute the (compiled during the process) IDL 
compiler tao_idl.exe, which randomly (more often than not) ends up in an 
STATUS_ACCESS_VIOLATION message and, some of these times with an 
additional comment saying "preprocessor 'g++' returned with an error" 
which crashes the application. After this I ran tao_idl.exe by hand, 
receiving the same outcome.

First I'll state that this is most probably not BLODA (unless some 
default program that comes with W7 provokes it), since I started with a 
fresh W7 installation made by myself on which I only installed Java JDK 
and Cygwin along with some of its packages.

I've been looking around and found several supposed workaraounds to this 
issue:
1.- peflags --tsaware=true app_name.exe
2.- Disable DEP (Data Execution Prevention)
3.- rebaseall -v
4.- rebaseall -v -T list_of_compiled_dlls

 From this list only the last solution worked for me, but it is very 
uncomfortable to have to run this in the middle of a compilation 
process, since, first of all, we need to stop all the cygwin processes. 
For ACE/TAO for example this would mean to compile it by sections, maybe 
rebasing after each set of DLLs. This would require, for instance, a 
batch (.bat or other windows based) script and several bash scripts to 
be called by it.

The thing is that later, when compiling Python (we use a specific 
version), a similar problem appeared (STATUS_ACCESS_VIOLATION messages 
that finish with a "fork: child -1 - died waiting for longjmp before 
initialization, retry 0, exit code 8800, errno 11", "error: Resource 
temporarily unavailable") when linking using gcc.

Also I would think that the problem is gcc/g++ related due to both 
problems comming from it, but in this scenario I can't understand at the 
moment why the problem appears only when linking some libs and not 
others and why is it solved when using rebaseall providing the list of 
DLLs created during compilation time as opposed to doing this with the 
system DLLs only.

Considering that the framework has a high number of modules(sets of libs 
and executables) I find a problem having to rebaseall after the 
compilation of each one.

We use gcc/g++ version (GCC) 4.3.4 20090804 (release) 1

I have three questions that you might ignore if there is an answer for 
the underlying problem.

    1.- For the external applications such as ACE/TAO or Python. What 
can we do to avoid running in the aformentioned problem without having 
to rebase in the middle of the compilation process? Looking at the 
linker flags of both ACE/TAO and Python, they already use the 
-Wl,--enable-auto-image-base linker flag.

    2.- Is it enough for the DLLs if they are compiled using the 
-Wl,--enable-auto-image-base linker flag? From the outcome I see from 
ACE/TAO and Python it seems that it isn't enough. What else can we do?

    3.- I know that WXP and W7 are very different, but is there 
something specific that causes these problem on W7 and not on WXP? I've 
been using Cygwin on WXP for some time and never had to rebase at all.

I prefered to leave out the snippets of code and errors to keep the mail 
relatively short. If you want to have a look at any of them or want me 
to show the output of a specific command, please let me know.

I appreciate your time reading this post and thank in advance any help 
or comment that you might share.

Best regards,
Tomás Staig.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple