Debug of Test 15 (cgf input needed)

[Pierre A. Humblet]

Chris, what you write makes perfect sense and I had tried it.
Here are more details.
I can see there are two threads, but bt and where tell me
"Cannot access memory at address 0x7cee8008" for both threads.
The only thing I can deduce by looking at the pc and the dll's
is that the program is in kernel32.

I also wrote a very simple program and repeated the procedure.
There attach doesn't hang, but I have the same memory
access problem. At any rate I don't have an unstripped version
of the cygwin dll to debug cygwin. I was simply hoping to confirm
that the program is in select.

Pierre

At 10:15 PM 4/7/2001 -0400, Christopher Faylor wrote:
>On Sat, Apr 07, 2001 at 09:55:43PM -0400, Pierre A. Humblet wrote:
>>At 08:14 PM 4/7/2001 -0400, Christopher Faylor wrote:
>>
>>>Some (most) select operations in cygwin actually need to resort to
>>>polling so they do consume CPU.  The easiest way to find out what is
>>>happening is to attach a gdb to the running process.
>>
>>Chris, can you elaborate? I have never done that until now.
>>While the Xserver process is running, I launch gdb -nw, load the executable
>>(file) and attach to the winpid. gdb tells me "attaching ... " and gets
>>stuck. From another window I send a signal to the Xserver and gdb
>>then gives me the prompt. Now what? The only info I have been able to
>>get is the registers and the dlls ...
>
>You need to investigate the stack frame, of course, with the "bt"
>command.  You need to see what threads are active with the 'info
>threads' command.  Then switch to the threads and do stack traces
>there to see what's going on.
>
>If you are debugging cygwin, you'll need to have an unstripped version
>of the DLL built with gcc -g.
>
>Hopefully this makes some sense.  I don't think I want to give a course
>in basic debugging.  If this doesn't make sense then I assume that there
>must be some information on the web somewhere on how to use gdb in
>addition to the gdb info files.
>
>cgf
>