displaying source after and before the program counter

displaying source after and before the program counter

[Vianney Lecroart]

Hello,

I have a C++ program that generates a core dump. I must activate
inlining because it's too slow. It crashes very rarely.

The program stack is:

#2  0x080597da in CBase<TRow>::operator()() const () at
/home/ace/src/gs/mpvi.h:451
#3  0x081e0c1f in CPhrase::update() (this=0x115245d8) at
/home/ace/src/gs/mpvi.h:527

The problem is that CPhrase::update() is a big function in a cpp file. I
would like to know the line where the call to mpvi.h:527 is made. I
can't see it because the function is inlining and it's an accessor, so,
it's called at least 50 times on this function.

The question is: Is it possible to know where in the function ::update()
the crash happened?

Vianney Lecroart
---
lead network programmer / nevrax.com
icq#: 6870415
homepage: http://ace.planet-d.net
www.geekcode.com: GCS/E d- s+++: a- C+++$UL++ P- L+++>+$ E+>- W++ N+ o?
K- w++$ O- M- V- PS- PE? Y PGP t 5? X+ R- tv++ b- DI D+ G e++ h-- r y?

Re: displaying source after and before the program counter

[Eli Zaretskii]

> From: "Vianney Lecroart" <lecroart@nevrax.com>
> Date: Mon, 15 Dec 2003 11:50:09 +0100
> 
> The problem is that CPhrase::update() is a big function in a cpp file. I
> would like to know the line where the call to mpvi.h:527 is made. I
> can't see it because the function is inlining and it's an accessor, so,
> it's called at least 50 times on this function.
> 
> The question is: Is it possible to know where in the function ::update()
> the crash happened?

Without turning off the inlining, yes?

Well, one way to do that is to look at the machine code in frame #3
(by using the `disassemble' command), then compare that with the
assembly generated by the compiler for the source code in question.
For the latter, invoke GCC exactly as it is invoked to compile the cpp
file which includes mpvi.h, but with the -S switch instead of the -c
switch.  (There are also switches that you can add to cause the
generated assembly to include source lines, which will make it easier
for you to associate the assembly with the source.)

HTH

Re: displaying source after and before the program counter

[Paul Koning]

>>>>> "Eli" == Eli Zaretskii <eliz@elta.co.il> writes:

 >> From: "Vianney Lecroart" <lecroart@nevrax.com> Date: Mon, 15 Dec
 >> 2003 11:50:09 +0100
 >> 
 >> The problem is that CPhrase::update() is a big function in a cpp
 >> file. I would like to know the line where the call to mpvi.h:527
 >> is made. I can't see it because the function is inlining and it's
 >> an accessor, so, it's called at least 50 times on this function.
 >> 
 >> The question is: Is it possible to know where in the function
 >> ::update() the crash happened?

 Eli> Without turning off the inlining, yes?

 Eli> Well, one way to do that is to look at the machine code in frame
 Eli> #3 (by using the `disassemble' command), then compare that with
 Eli> the assembly generated by the compiler for the source code in
 Eli> question.

Here's another approach:

Invoke the program via gdb.  Set a breakpoint at the address shown in
the call stack.  Start the program.

When the breakpoint hits, step to the next line ("n") until you're
back in the cpp file.  You're now near the inline function call you
need, most likely at the next line.  (Perhaps not quite, depending on
how much the optimizer has moved things around.

    paul

Re: displaying source after and before the program counter

[Daniel Jacobowitz]

On Mon, Dec 15, 2003 at 11:50:09AM +0100, Vianney Lecroart wrote:
> Hello,
> 
> I have a C++ program that generates a core dump. I must activate
> inlining because it's too slow. It crashes very rarely.
> 
> The program stack is:
> 
> #2  0x080597da in CBase<TRow>::operator()() const () at
> /home/ace/src/gs/mpvi.h:451
> #3  0x081e0c1f in CPhrase::update() (this=0x115245d8) at
> /home/ace/src/gs/mpvi.h:527
> 
> The problem is that CPhrase::update() is a big function in a cpp file. I
> would like to know the line where the call to mpvi.h:527 is made. I
> can't see it because the function is inlining and it's an accessor, so,
> it's called at least 50 times on this function.
> 
> The question is: Is it possible to know where in the function ::update()
> the crash happened?

In addition to the other suggestions you've gotten, you can work this
out by hand from the debug information; however, it's a bit of a pain
to do and you have to get familiar with DWARF-2.  GDB has enough
information to do this for you but currently doesn't support it. 
Hopefully that will change sometime next year.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer