This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: This is a Cygwin failure yeah?
Bernd Roesch wrote:
> 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.
You can't assume that actually was a stack overflow just because the stack
ended up corrupted.
> 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.
Yes, on Windows platforms the per-thread stack allocation is encoded in the
executable file header at compile/link time. This is managed by passing the
--stack option to the final link (often using -Wl, on the gcc command-line.)
> maybe on GGC code can add that it use always 2 MB stack ????
> cygwin bash only have 400 kb of stack.
Not so, actually - the current Cygwin bash was compiled with a 2MB stack
anyway:
/bin $ dumpbin /headers bash.exe
Microsoft (R) COFF Binary File Dumper Version 6.00.8168
Copyright (C) Microsoft Corp 1992-1998. All rights reserved.
Dump of file bash.exe
PE signature found
File Type: EXECUTABLE IMAGE
FILE HEADER VALUES
14C machine (i386)
5 number of sections
49316968 time date stamp Sat Nov 29 16:10:16 2008
[ ... snip ... ]
OPTIONAL HEADER VALUES
10B magic #
2.56 linker version
[ ... snip ... ]
200000 size of stack reserve
1000 size of stack commit
[ ... snip ... ]
> Unix commad for stack increase(forget the name)
'ulimit'
> dont work
Yes, because of the way the stack size is specified in the file header as
mentioned above. It's one of the places where Cygwin's emulation of *nix is
limited by the behaviour of the underlying Windows OS.
> the exception handler of cygwin seem too broken, because a abort give always
> this message and no abort text.
It does often fail. It can't unwind the stack through Windows API
functions where the system DLL was compiled with FPO. (It may have bugs, of
course, as well.)
> 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.
That's a very old version, and there used to be a lot of bugs handling
corrupt or over-long lines; it was probably trying to read the whole thing
into a buffer that was only really big enough for one line.
> 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
? ISTR there have been minor tweaks down the years to the behaviour of the
preprocessor when it comes to continued strings across line-ends. Might be
related.
cheers,
DaveK