Mail Archives: cygwin/2006/03/03/14:55:54
On 03 March 2006 19:39, Dave Korn wrote:
> On 03 March 2006 17:13, Dave Korn wrote:
>
>> On 03 March 2006 16:39, Christian Franke wrote:
>
>>> Steps to reproduce on XP Prof:
>
>>> $ CYGWIN=nontsec ls "/cygdrive/c/System Volume Information"
>>> ls: /cygdrive/c/System Volume Information: Permission denied
>>> # *** ls hangs with 100% CPU ***
>>>
>>> Bug is present since cygwin1.dll 20050128, 20050127 was OK.
>
>> It appears to be running to completion and then hitting an infinite loop
>> at
>>
>> (gdb) info symbol 0x61002148
>> _cfree AT 4 + 40 in section .text
>>
>> which is called from exit(). Can't do better than that yet, I can't seem
>> to get these separate .dll/.dbg files to play together right now...
>
>
> OK, there's been an exception. It keeps on hitting
>
> _cygtls::handle_exceptions(_EXCEPTION_RECORD*, _exception_list*, _CONTEXT*,
> void *)
>
> which returns 1 (EXCEPTION_EXECUTE_HANDLER). Not quite sure what happens
> next or how it got there, but the SEH chain is looping:
>
>
> 0:000> t
> eax=00000000 ebx=0022fbb8 ecx=00000000 edx=7c9037d8 esi=0022e7f8
> edi=00000001 eip=7c92aa1b esp=0022e770 ebp=0022e7e0 iopl=0 nv up ei
> pl zr na po nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000
> efl=00000246 ntdll!RtlDispatchException+0x139:
> 7c92aa1b 8b1b mov ebx,[ebx]
> ds:0023:0022fbb8=0022fbb8 0:000> t
> eax=00000000 ebx=0022fbb8 ecx=00000000 edx=7c9037d8 esi=0022e7f8
> edi=00000001 eip=7c92aa1d esp=0022e770 ebp=0022e7e0 iopl=0 nv up ei
> pl zr na po nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000
> efl=00000246 ntdll!RtlDispatchException+0x13b:
> 7c92aa1d 83fbff cmp ebx,0xffffffff
> 0:000> t
> eax=00000000 ebx=0022fbb8 ecx=00000000 edx=7c9037d8 esi=0022e7f8
> edi=00000001 eip=7c92aa20 esp=0022e770 ebp=0022e7e0 iopl=0 nv up ei
> pl nz ac pe cy cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000
> efl=00000213 ntdll!RtlDispatchException+0x13e:
> 7c92aa20 0f846cce0000 je ntdll!RtlDispatchException+0x150 (7c937892)
> [br=0] 0:000> t
> eax=00000000 ebx=0022fbb8 ecx=00000000 edx=7c9037d8 esi=0022e7f8
> edi=00000001 eip=7c92aa26 esp=0022e770 ebp=0022e7e0 iopl=0 nv up ei
> pl nz ac pe cy cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000
> efl=00000213 ntdll!RtlDispatchException+0x144:
> 7c92aa26 e9dacd0000 jmp ntdll!RtlDispatchException+0x49 (7c937805)
> 0:000> dd ebx
> 0022fbb8 0022fbb8 61018630 00000000 00000000
>
> and it's running round and round calling the SEH filter over and over and
> over again. Will post more as I get it.
>
Right, so we're here:
/* Main exception handler. */
extern "C" char *__progname;
int
_cygtls::handle_exceptions (EXCEPTION_RECORD *e, exception_list *frame,
CONTEXT *in, void *)
{
static bool NO_COPY debugging;
static int NO_COPY recursed;
_cygtls& me = _my_tls;
if (debugging && ++debugging < 500000)
{
SetThreadPriority (hMainThread, THREAD_PRIORITY_NORMAL);
return 0;
}
/* If we've already exited, don't do anything here. Returning 1
tells Windows to keep looking for an exception handler. */
if (exit_already || e->ExceptionFlags)
return 1;
and the 1 is getting returned because the problem has arisen during the
processing of exit() for the main thread (whatever the original underlying
problem is), and 1 means 'keep looking', but of course because the SEH chain
has become circular it just keeps on going forever.
That's interesting. How is re-throwing an SEH exception meant to deal with
the possibility that the stack (where the SEH registration chain) lives may
possibly have become messed up?
cheers,
DaveK
--
Can't think of a witty .sigline today....
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -