This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: This is a Cygwin failure yeah?


Hello Andy

On 07.01.09, you wrote:


> Cygwin one:
> 
> When it gets to stage 3 (after many hours) I get the following printed
> out to the console (not redirected) -
> 
> 217 [unknown (0x1B0)] conftest 3408 _cygtls::handle_exceptions: Error
> while dumping state (probably corrupted stack)
> 

I think its a problem that cygwin cant use more stack.and in some case there
get a stack overflow.but it seem not possible to increase the stack for the
cygwin bash(i read many about that in inet but no solution see).only
solution seem to build the build gcc with the stack option that the fvork
for start cc1 use more stack than the bash process.

maybe on GGC code can add that it use always 2 MB stack ????
cygwin bash only have 400 kb of stack.Unix commad for stack increase(forget
the name) dont work

the exception handler of cygwin seem too broken, because a abort give always
this message and no abort text.

I btw get such crashes from binutil 2.14 assembler and can reproduce them
when i forget on writing asm inline code a \n\ at end.

normaly the assembler give error messages, but i guess due too much stack of
assembler error writing, gcc crash because of too few stack.

strange, compiler 2.95 and older binutil work without \n\ at end

> By the looks of this I wold say that some part of the Cygwin runtime
> has failed. I've not seen this one in Cygwin at any other time than
> building GCC which leads me to assume (which is dangerous I realise)
> that there is an issue with my version and how GCC builds. Placing the
> "blame" on the Cygwin runtime.
> 
> Is this a correct assumption can anyone tell me? [obviously if it is a
> Cygwin issue then I'll track it down a bit more before posting on
> their forums]
> 
> GCC Build One:
> 
> Again stage3 part of build, and this is what actually stops the build
> the above issue doesn't seem to (I think it happens in stage 2), I get
> the following:
> 
> <many, many, many lines of log deleted>
> 
>     /home/andy/live-gcc/my_gcc/./gcc/xgcc
> -B/home/andy/live-gcc/my_gcc/./gcc/ -B/usr/local/i686-pc-cygwin/bin/
> -B/usr/local/i686-pc-cygwin/lib/ -isystem
> /usr/local/i686-pc-cygwin/include -isystem
> /usr/local/i686-pc-cygwin/sys-include -c -DHAVE_CONFIG_H -g -O2    -I.
> -I../../../gcc/libiberty/../include  -W -Wall -Wwrite-strings
> -Wc++-compat -Wstrict-prototypes -pedantic
> ../../../gcc/libiberty/strsignal.c -o pic/strsignal.o; \
>   else true; fi
> /home/andy/live-gcc/my_gcc/./gcc/xgcc -B/home/andy/live-gcc/my_gcc/./gcc/
> -B/usr/local/i686-pc-cygwin/bin/ -B/usr/local/i686-pc-cygwin/lib/ -isystem
> /usr/local/i686-pc-cygwin/include -isystem
> /usr/local/i686-pc-cygwin/sys-include -c -DHAVE_CONFIG_H -g -O2 -I.
> -I../../../gcc/libiberty/../include -W -Wall -Wwrite-strings -Wc++-compat
> -Wstrict-prototypes -pedantic ../../../gcc/libiberty/strsignal.c -o
> strsignal.o ../../../gcc/libiberty/strsignal.c:408: error: conflicting
> types for 'strsignal' /usr/include/string.h:78: note: previous declaration
> of 'strsignal' was here make[2]: *** [strsignal.o] Error 1 make[2]:
> Leaving directory `/home/andy/live-gcc/my_gcc/i686-pc-cygwin/libiberty'
> make[1]: *** [all-target-libiberty] Error 2 make[1]: Leaving directory
> `/home/andy/live-gcc/my_gcc' make: *** [all] Error 2
> 
> Which seems like a possible setup/build issue. If this is so anyone
> seen it before and any helpful hints on how to get rid of it?
> 
> Thanks.
> 
> Andy
Regards


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]