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 ?
Bob
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.
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
On Sun, 10 Jul 2005 14:07:53 +1000, Robert Lunnon wrote:
OK, what do you mean the kernel doesn't allow you to do that - Suspend a thread or ??? Why not just write a SIGSTOP
SIGSTOP has process scope on NPTL, I think.
If SIGUSR1 isn't handled, then stuff will break mysteriously. Essentially all it does is block on a wineserver fd until the thread is woken up again. In future it'll also store the sigcontext so copy protection and such works.
thanks -mike
-
Mike Hearn -
Robert Lunnon -
Robert Shearman