Debugger startup

[Robert Lunnon]

On Sunday 10 July 2005 09:38, Robert Shearman wrote:
> Robert Lunnon wrote:
> >To implement a Solaris debugger I have traced the wineservers startup and
> >there is something I don't understand. I get the following stack trace:
> >
> >send_thread_signal+0x4a(80aab90, 10)
> >stop_thread+0x1f(80aab90)
> >suspend_process+0x4d(81c72a8)
> >debugger_attach+0xf1(81c72a8, 81d1b58)
> >req_debug_process+0x4c(81d1c38, 80477a0)
> >call_req_handler+0x74(81d1b58)
> >read_request+0x68(81d1b58)
> >thread_poll_event+0x62(81d22b0, 1)
> >fd_poll_event+0x14(81d22b0, 1)
> >main_loop+0x9e(804785c, 8056a51, 1, 8047868, 8047870, 804785c)
> >main+0xc6(1, 8047868, 8047870)
> >_start+0x5d(1, 804795c, 0, 8047979, 80479f6, 8047a0a)
> >
> >bebugger_attach calls suspend_process then stop_thread
> >
> >stop_thread sends a SIGUSR1 at the thread of interest. The result of this
> > is that the thread is terminated and there is nothing to attach to....
> >
> >Why is this SIGUSR1 sent ?
>
> It is the way suspending processes is done because the kernel doesn't
> allow us to do it. The handler should be installed in the file
> dlls/ntdll/signal_i386.c. You probably want to find out why it isn't
> being installed correctly.

OK, what do you mean the kernel doesn't allow you to do that - Suspend a 
thread or ??? Why not just write a SIGSTOP

Anyway I think I have worked past this but I now have run into a problem 
whereby procfs returns EBUSY on a control file write to start or single step 
a process which should only happen if the thread isn't stopped. My code 
though indicates it is stopped (I test the threads status to find out before 
I issue the run)  

Very Odd.

Bob