Debugging remotely from Visual studio

[David Hemmo]

Hello,

After reading a mail exchanges about ptrace on Linux, I decided to 
switch to a newer Linux kernel to see how it modified my problem.

Things got worse. Restarting a program from Visual studio stopped working.

Is there anyone that can explain me how things are supposed to work ?

I think I know the basics. To start, the debugger set the bit 0x100 in 
EFlags ot the current context, then wine test this bit to check what 
parameter to send to ptrace to restart the process. It gets blurry after 
that ... What happens after the traced instruction executes ?

At least three parts are involved:
- Linux that handle the first part of the exception
- Wineserver
- msvcmon. It is the visual C++ remote debugging program, but I think it 
could be any debugger.
There may be a 4th player with the exception handling part of the 
debugged application but I am not sure.

Thanks

David

[Eric Pouech]

David Hemmo a écrit :
> Hello,
>
> After reading a mail exchanges about ptrace on Linux, I decided to 
> switch to a newer Linux kernel to see how it modified my problem.
>
> Things got worse. Restarting a program from Visual studio stopped working.
>
> Is there anyone that can explain me how things are supposed to work ?
>
> I think I know the basics. To start, the debugger set the bit 0x100 in 
> EFlags ot the current context, then wine test this bit to check what 
> parameter to send to ptrace to restart the process. It gets blurry after 
> that ... What happens after the traced instruction executes ?

- kernel send a trap signal
- wine's ntdll catches it, and queue the information as a debug event in the 
wineserver
- the debugger (msvcmon in your case) get notified of the trap while waiting for 
a debug event

A+

[David Hemmo]

Eric Pouech wrote:
> - kernel send a trap signal
> - wine's ntdll catches it, and queue the information as a debug event in
>
> the wineserver
> - the debugger (msvcmon in your case) get notified of the trap while
>
> waiting for a debug event

I understand.

I made a log of what happens when I single step with the debugger:

I see the debugger waking up
001b: *wakeup* signaled=258 cookie=0x2f9ce4
then, a little further it get the exception status
001b: get_exception_status() = 0 
{status=65538,context={flags=00010007,...,eflags=00210346,...}}
and then the same thread has a lot of lines in the log with the same message
001b: *signal* signal=5
until the message
001b:warn:seh:setup_exception exception outside of stack limits in 
thread 001b eip 002b448d esp 019b12ec stack 0x19b0000-0x1ab0000

It clearly looks like a recursive call, or an infinite loop.

Any idea of what can trigger such a behaviour ?

Another question that could be related is the status of the trace flag 
in EFlags (0x100). It looks like wine clears it in some of its code 
(raise_trap_exception and the handler for SIGTRAP in signal_i386.c). 
Shouldn't it be the debugger responsibilty ?

Thanks

David Hemmo

PS: I hope I am clear enough. Don't hesitate to contact me if anything 
is missing, or not clear.

[Eric Pouech]

David Hemmo a écrit :
> Eric Pouech wrote:
> > - kernel send a trap signal
> > - wine's ntdll catches it, and queue the information as a debug event
> >
> > in the wineserver
> > - the debugger (msvcmon in your case) get notified of the trap while
> >
> > waiting for a debug event
>
> I understand.
>
> I made a log of what happens when I single step with the debugger:
>
> I see the debugger waking up
> 001b: *wakeup* signaled=258 cookie=0x2f9ce4
> then, a little further it get the exception status
> 001b: get_exception_status() = 0 
> {status=65538,context={flags=00010007,...,eflags=00210346,...}}
> and then the same thread has a lot of lines in the log with the same 
> message
> 001b: *signal* signal=5
> until the message
> 001b:warn:seh:setup_exception exception outside of stack limits in 
> thread 001b eip 002b448d esp 019b12ec stack 0x19b0000-0x1ab0000

what's strange is that esp is within stack limit... wine exception handler must 
this from another part... it may come from msvcmon tweaking the selectors (cs, 
ss) for some reasons
A+

[David Hemmo]

> what's strange is that esp is within stack limit... wine exception  
> handler must this from another part... it may come from msvcmon  
> tweaking the selectors (cs, ss) for some reasons

I agree it is strange but it still comes up after a bunch of  "001b:  
*signal* signal=5" that should not be there.
Any idea how I can trace the cause for the repetition of this  
signal ? Or how I can fix it ?

Thanks

David

[Eric Pouech]

David Hemmo a écrit :
> > what's strange is that esp is within stack limit... wine exception  
> > handler must this from another part... it may come from msvcmon  
> > tweaking the selectors (cs, ss) for some reasons
>
> I agree it is strange but it still comes up after a bunch of  "001b:  
> *signal* signal=5" that should not be there.

are you sure they are all from the same address ? if not, it only means the 
program is being single stepped.
> Any idea how I can trace the cause for the repetition of this  signal ?

we didn't change much in this area lately.
> Or how I can fix it ?

can you send me the whole +seh,+server trace. TIA

A+