Hello Dave

On 09.01.09, you wrote:

> 
>  You can't assume that actually was a stack overflow just because the
> stack ended up corrupted.
> 

yes thats the problem, because a assert give this message too.maybe the
program do assert.
maybe theres a way that cygwin print out the assert text earlier when call
assert
?
and cygwin show on this message how many stack is currently value =
stackpointer -stackbase

this maybe help to see better whats the problem.

> 
>> Unix commad for stack increase(forget the name)
> 
>  'ulimit'

ah yes i see, I update from time and time and now its more.my bash show this
now.Maybe Andy can do this test what his bash show.

$ ulimit -a
core file size          (blocks, -c) unlimited
data seg size           (kbytes, -d) unlimited
file size               (blocks, -f) unlimited
open files                      (-n) 256
pipe size            (512 bytes, -p) 8
stack size              (kbytes, -s) 2033
cpu time               (seconds, -t) unlimited
max user processes              (-u) 63
virtual memory          (kbytes, -v) 2097152


> 
>  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 do test program some time ago, I try assert and throw_logic_error it get
always the known error and print no text on cygwin.

I try the cygwin gcc3 and 4 from installer.

> 
>> 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.

I see on gcc programs (gcc source) always have a /n/ at end of line.seem the
syntax is change.I find the old syntax better, because i need not type so
much chars

when i see programs that are compile on gcc 2.95 well, these are not in and
it seem work with older binutil.

for example on older compiler this work

 asm (" 
    movel a5,a0 
    lea   Lget_sr,a5 
    movel 4:w,a6
    jsr   a6@(-0x1e) 
    movel a1,%0 
    bra   Lskip 
    Lget_sr: 
    movew sp@,a1        | get sr register from the calling function \n\
    rte 
    Lskip: 
    movel a0,a5 
        " : "=g" (sr) : : "a0", "a1", "a6");
    } 

compiler > = 3.4.0 and above crashes or print out large error messages.
Now i do the test, no cygwin crash only assembler errors.maybe the larger
stack help...

../../../kern_sig.c:783: error: missing terminating " character
../../../kern_sig.c:784: error: `movel' undeclared (first use in this
function)
../../../kern_sig.c:784: error: (Each undeclared identifier is reported only
onc
e
../../../kern_sig.c:784: error: for each function it appears in.)
../../../kern_sig.c:784: error: syntax error before "a5"
../../../kern_sig.c:787: error: stray '@' in program
../../../kern_sig.c:791: error: stray '@' in program
../../../kern_sig.c:795: error: missing terminating " character

only this version below compile correct.

 asm volatile (" \n\
    movel a5,a0 \n\
    lea   Lget_sr,a5 \n\
    movel 4:w,a6 \n\
    jsr   a6@(-0x1e) \n\
    movel a1,%0 \n\
    bra   Lskip \n\
    Lget_sr: \n\
    movew sp@,a1        | get sr register from the calling function \n\
    rte \n\
    Lskip: \n\
    movel a0,a5 \n\
        " : "=g" (sr) : : "a0", "a1", "a6");

> 
>    cheers,
>      DaveK
Regards

Reply via email to