RE: Breaking outside of the sources

RE: Breaking outside of the sources

[pmcgarry]

> -----Original Message-----
> From: Laurent Duperval [ mailto:lduperval@microcelli5.com ]
> Sent: Tuesday, April 24, 2001 4:22 PM
> To: GDB Mailing List
> Subject: Re: Breaking outside of the sources
> 
> 
> On 24 Apr, Keith Seitz wrote:
> > On Tue, 24 Apr 2001, Laurent Duperval wrote:
> > 
> >> Someone sent an email on the insight list complaining that 
> when gdb is
> >> interrupted, you can find yourself stuck in assembly in a line of
> >> /lib/libc.so instead of a line from your program. He asked 
> whether it was
> >> possible to limit the lines seen to the programs being 
> debugged and not to
> >> see system library stuff. I thought it was a a legitimate question.
> > 
> > If you interrupt a system call (you were blocked in select, 
> poll, read, 
> > write, etc), then gdb dutifully prints out that you are 
> there, because 
> > your program IS there. It is not somewhere else, it is in 
> the system 
> > call, executing code in a (possibly shared) system library.
> > 
> 
> Right.
> 
> > Of course, I could misunderstand this question entirely. It 
> sounds like 
> > the user is requesting that the debugger lie to him about what his 
> > program is executing...
> > 
> 
> Not really. Often, breaking in system libraries doesn't 
> provide interesting
> feedback. If I interrupt the program, most of the time I'm 
> not interested in
> knowing that I was in poll(), select() or other sytem calls. But I am
> interested in knowing in which part of my code the poll(), 
> select()... was
> called. Most of the time it can be done using the stacktrace 
> but for new
> users (especially) it adds an unwanted (unneeded?) level of 
> complexity.
> 
> I think (I dunno, I haven't used them in a while) that's the way MS
> debuggers work.

Actually, the MS VC++ integrated debugger (and all other good debuggers that
I know of) actually break in the system call if that is where you are!  So
it doesn't surprise me at all that gdb would do the same thing - it is the
'right' thing to do.

The reasons are actually quite simple, and the two most important are that
1) that's what most good engineers want anyway, and 2) you want to know
exactly what the code is/was doing when it broke.  

It really should not be considered an added level of complexity; in fact, it
helps you to determine what the nature of your problem actually is.  

For example, if you end up with memory access violations, etc., and they
appear to be occuring in system code, then chances are you have corrupted
pointer data or have overwritten memory, and then you can start focusing on
investigating the calling chain to determine just what caused the bubble to
burst.

Another good example is when you end up with the (n)ever-popular
sprintf/printf problems where parameters don't match up correctly.  Noting
failures in resultant system calls can often point you right to such a
problem.

You can often times get an idea of what caused the problem by investigating
the register sets at the particular point of failure in the system call.
Perhaps you will be lucky enough to note that one of the values looks like
an address, and dereferencing such an address seems to show you some data
that correlates to a routine that you recently changed.  This 'luckiness'
can happen more often than you might think.  :)

Most of these situations can of course be handled via the stack trace or any
other similar mechanism you may have available in your particular debugger -
I am not a consistent user of gdb, so I can't speak as to the facilities
there but I'm sure others on this list can.  From the stack trace, you
should be able to select any of the methods/functions in the calling chain
and investigate the local scope for the individual pieces of code that led
up to the problem itself, which just happened to finally materialize in the
system call.

Finally, remember that some notoriously-difficult-to-debug problems take
time and effort for even expert programmers and expert debuggers to figure
out.  You just have to be ready and willing to fight the good fight!

Pat

Re: Breaking outside of the sources

[Keith Seitz]

On Tue, 24 Apr 2001, Laurent Duperval wrote:

> Not really. Often, breaking in system libraries doesn't provide interesting
> feedback. If I interrupt the program, most of the time I'm not interested in
> knowing that I was in poll(), select() or other sytem calls. But I am
> interested in knowing in which part of my code the poll(), select()... was
> called. Most of the time it can be done using the stacktrace but for new
> users (especially) it adds an unwanted (unneeded?) level of complexity.

Oh, I see. Well, this is part of the ropes, though. Debuggers are not 
tools designed for novices. They are designed for the serious (if not 
professional) programmer/engineer.

> I think (I dunno, I haven't used them in a while) that's the way MS
> debuggers work.

Hmm. Been a few months since I used VisualStudio, but I would guess that 
all it does is change the debugger's stack frame. You're still in the system 
call.

The only way for the debugger to stop your program outside a system 
library would be for it to have a lot of intimate knowledge of the 
program and all of the system libraries. It would need to step you out of the 
system call, but it could not do this with, for example, any blocking 
system call.

Keith

Re: Breaking outside of the sources

[Laurent Duperval]

On 24 Apr, Keith Seitz wrote:
> On Tue, 24 Apr 2001, Laurent Duperval wrote:
> 
>> Someone sent an email on the insight list complaining that when gdb is
>> interrupted, you can find yourself stuck in assembly in a line of
>> /lib/libc.so instead of a line from your program. He asked whether it was
>> possible to limit the lines seen to the programs being debugged and not to
>> see system library stuff. I thought it was a a legitimate question.
> 
> If you interrupt a system call (you were blocked in select, poll, read, 
> write, etc), then gdb dutifully prints out that you are there, because 
> your program IS there. It is not somewhere else, it is in the system 
> call, executing code in a (possibly shared) system library.
> 

Right.

> Of course, I could misunderstand this question entirely. It sounds like 
> the user is requesting that the debugger lie to him about what his 
> program is executing...
> 

Not really. Often, breaking in system libraries doesn't provide interesting
feedback. If I interrupt the program, most of the time I'm not interested in
knowing that I was in poll(), select() or other sytem calls. But I am
interested in knowing in which part of my code the poll(), select()... was
called. Most of the time it can be done using the stacktrace but for new
users (especially) it adds an unwanted (unneeded?) level of complexity.

I think (I dunno, I haven't used them in a while) that's the way MS
debuggers work.

L

-- 
Laurent Duperval < mailto:lduperval@microcelli5.com >

Re: Breaking outside of the sources

[Keith Seitz]

On Tue, 24 Apr 2001, Laurent Duperval wrote:

> Someone sent an email on the insight list complaining that when gdb is
> interrupted, you can find yourself stuck in assembly in a line of
> /lib/libc.so instead of a line from your program. He asked whether it was
> possible to limit the lines seen to the programs being debugged and not to
> see system library stuff. I thought it was a a legitimate question.

If you interrupt a system call (you were blocked in select, poll, read, 
write, etc), then gdb dutifully prints out that you are there, because 
your program IS there. It is not somewhere else, it is in the system 
call, executing code in a (possibly shared) system library.

Of course, I could misunderstand this question entirely. It sounds like 
the user is requesting that the debugger lie to him about what his 
program is executing...

Keith

Breaking outside of the sources

[Laurent Duperval]

Hi,

Someone sent an email on the insight list complaining that when gdb is
interrupted, you can find yourself stuck in assembly in a line of
/lib/libc.so instead of a line from your program. He asked whether it was
possible to limit the lines seen to the programs being debugged and not to
see system library stuff. I thought it was a a legitimate question.

L

-- 
Laurent Duperval < mailto:lduperval@microcelli5.com >