This is the mail archive of the cygwin mailing list for the Cygwin 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: Shells hang during script execution

On Wed, Mar 01, 2006 at 10:47:59AM -0500, Paul Clements wrote:
>Christopher Faylor wrote:
>>It's also in the latest snapshot:
>I got the latest cygwin dll snapshot (20060227) a few days ago and I've 
>been stress testing ksh with this new dll since.
>The good news is that the hang issues (signal related) that I was seeing 
>appear to be fixed by your patches. I've not seen the either of the two 
>hangs with this snapshot. Thanks Christopher.
>The bad news is that I'm now seeing a segmentation violation (4 or 5 
>times so far) that I was not seeing before. I don't know if fixing the 
>hangs has allowed me to get to this point, or if the crashes are due to 
>the patches (hard to see how that could be the case). I'm having trouble 
>figuring out how the crash occurred, because the last address in the 
>stackdump looks bogus. I'm not sure if there's any significance to that 
>(could it be a signal handler that was injected into the stack, or could 
>this be due to stack corruption, or does this look normal?). Anyway, 
>below is the stack trace and (very simple) test script I'm running. Any 
>ideas or suggestions on things to try?

The obvious thing to try would be to actually inspect the source code
up the stack around where the error occurred.  You'll have to make a
debugging version of ksh for that.

You can also set CYGWIN=error_start:/path/to/gdb.exe to have cygwin pop
up an instance of gdb whenever the program is about to die.


>$ cat ksh.exe.stackdump
>eax=00000000 ebx=FFFFFFFF ecx=610FE084 edx=0022F064 esi=00484283 
>ebp=0022E848 esp=0022E830 program=c:\lk\bin\ksh.exe, pid 1816, thread main
>cs=001B ds=0023 es=0023 fs=003B gs=0000 ss=0023
>Stack trace:
>Frame     Function  Args
>0022E848  0022FBFC  (00484660, 00000000, 0009C05C, 0041E1F2)
>0022E938  0040AB39  (00486C18, 0022E950, 00000020, 004896C8)
>0022E968  0040A0FA  (00486C18, 00000020, 004895F0, 00000000)
>0022E9B8  0040CFA8  (00486C50, 00000000, 00486B38, 00000000)
>0022EA38  0040C4C1  (00486C50, 00000000, 004895F4, 00000100)
>0022EAB8  0040C665  (00486C80, 00000000, 00486888, 00000000)
>0022EB38  0040CAFD  (004867B8, 00000000, 0022EB88, 00000003)
>0022EBB8  0040C68E  (004867B8, 00000000, 0022EBE8, 0041A317)
>0022EC38  0040C68E  (00487350, 00000000, 0022EC68, 00416A9A)
>0022EC68  004166FB  (004850E8, 00000001, 00000000, 00000030)
>0022EEC8  004162B2  (00000002, 6115E7B4, 00480090, 77DBD397)
>0022EF78  61005BC8  (0022EFD0, 0022EFFC, C0150008, 00000000)
>0022FF88  61005EB3  (00000000, 00000000, 00000000, 00000000)
>End of stack trace
>Corresponding symbols:
>22fbfc ??     (this address looks bogus)
>40ab39 expand (40ab39 is after the call to waitlast)
>40a0fa evalstr
>40cfa8 comexec
>The test case is very simple. I just run three copies of ksh like this:
>ksh ./
>--- ---
>while [ $i -lt $n ]
>        x=`echo a:$i | cut -d: -f1`
>        i=$(( $i + 1 ))
>        m=$(( $i % 1000 ))
>        if [ $m -eq 0 ]; then echo -n $i: $$:; date; fi

Unsubscribe info:
Problem reports:

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