So now I got very frequent segfaults in my development version of POV-Ray -
frequent enough to be reproducible even with the non-optimized debug version
within a few seconds. Time to track them down with valgrind and gdb.

Hum... so now I know in which *function* it crashes - but what do I have to do
in order to get the *line number*??

Digging through assembler code and trying to match it with the C++ source code
is a bit cumbersome, so I guess there *must* be an easier way... even Linux
jockeys can't be *that* masochistic :)

I knew I wouldn't like debugging under Linux :S

Post a reply to this message

> So now I got very frequent segfaults in my development version of POV-R
ay -
> frequent enough to be reproducible even with the non-optimized debug ve
rsion
> within a few seconds. Time to track them down with valgrind and gdb.
> 
> Hum... so now I know in which *function* it crashes - but what do I hav
e to do
> in order to get the *line number*??
> 
> Digging through assembler code and trying to match it with the C++ sour
ce code
> is a bit cumbersome, so I guess there *must* be an easier way... even L
inux
> jockeys can't be *that* masochistic :)
> 
> I knew I wouldn't like debugging under Linux :S
> 
> 
> 


To debug, you should run povray with gdb. Then you'll be able to add 
breakpoint and/or view the stack-trace on a segfault

another way is to integrate povray sources in a project under KDevelop 
and then run in debug mode .. it will show you the "wrong" code

good luck

Post a reply to this message

On Mon, 02 Feb 2009 11:54:22 -0500, clipka wrote:

> So now I got very frequent segfaults in my development version of
> POV-Ray - frequent enough to be reproducible even with the non-optimized
> debug version within a few seconds. Time to track them down with
> valgrind and gdb.
> 
> Hum... so now I know in which *function* it crashes - but what do I have
> to do in order to get the *line number*??
> 
> Digging through assembler code and trying to match it with the C++
> source code is a bit cumbersome, so I guess there *must* be an easier
> way... even Linux jockeys can't be *that* masochistic :)
> 
> I knew I wouldn't like debugging under Linux :S

I'd second Thierry's suggestion - make sure you also compile with 
symbolic information enabled (-g as I recall).

Another approach would be to run the program under strace.  gdb will give 
you the ability to look at the call stack, though, where strace will just 
give you a starting point.

Jim

Post a reply to this message

Thierry CHARLES <thierry@_no_spam_les-charles.net> wrote:
> To debug, you should run povray with gdb. Then you'll be able to add
> breakpoint and/or view the stack-trace on a segfault

I can get a stack trace from the coredump - but it doesn't show line numbers.

I can also get interesting information from valgrind - but it doesn't give me
line numbers either.

> another way is to integrate povray sources in a project under KDevelop
> and then run in debug mode .. it will show you the "wrong" code

.... and I'm not really eager to set up some KDevelop project:

- Getting an existing project to compile in yet another IDE typically sucks.

- Getting it to compile in an IDE you don't know sucks even more.

- Getting it to compile in an IDE you haven't even installed (ever) sucks like
crazy.

- Getting it to compile in an IDE that, by its name, seems to require a GUI
(KDE) you haven't even installed (ever) promises to be really sucking like
hell.

If I had my way, I'd prefer that sneaky piece of software to crash on my Windows
machine as well, where I have a nice, familiar IDE at hand and a project already
set up for it :S

Post a reply to this message

> Thierry CHARLES <thierry@_no_spam_les-charles.net> wrote:
>> To debug, you should run povray with gdb. Then you'll be able to add
>> breakpoint and/or view the stack-trace on a segfault
> 
> I can get a stack trace from the coredump - but it doesn't show line nu
mbers.
> 
> I can also get interesting information from valgrind - but it doesn't g
ive me
> line numbers either.
> 

If you compile your code using -g (or -dgdb if you plan to use gdb and 
get some more specific results) you will have row numbers :

man gcc :
        -g*level*
       Request debugging information and also use level to specify how
       much information.  The default level is 2.

       Level 0 produces no debug information at all.  Thus, -g0 negates
       -g.

       Level 1 produces minimal information, enough for making backtraces


       includes descriptions of functions and external variables, but no
       information about local variables and no line numbers.

       Level 3 includes extra information, such as all the macro
       definitions present in the program.  Some debuggers support macro
       expansion when you use -g3.


>> another way is to integrate povray sources in a project under KDevelop

>> and then run in debug mode .. it will show you the "wrong" code
> 
> .... and I'm not really eager to set up some KDevelop project:
> 
> - Getting an existing project to compile in yet another IDE typically s
ucks.
> 
> - Getting it to compile in an IDE you don't know sucks even more.
> 
> - Getting it to compile in an IDE you haven't even installed (ever) suc
ks like
> crazy.
> 
> - Getting it to compile in an IDE that, by its name, seems to require a
 GUI
> (KDE) you haven't even installed (ever) promises to be really sucking l
ike
> hell.
> 
> If I had my way, I'd prefer that sneaky piece of software to crash on m
y Windows
> machine as well, where I have a nice, familiar IDE at hand and a projec
t already
> set up for it :S
> 
> 
>

Post a reply to this message

Thierry CHARLES <thierry@_no_spam_les-charles.net> wrote:
> If you compile your code using -g (or -dgdb if you plan to use gdb and
> get some more specific results) you will have row numbers :

I guess I'll need to figure out which of these are set by the ./configure
options available for POV-Ray, and how the Intel compiler deals with them...

Thanks for the info.

Post a reply to this message

> Thierry CHARLES <thierry@_no_spam_les-charles.net> wrote:
>> If you compile your code using -g (or -dgdb if you plan to use gdb and

>> get some more specific results) you will have row numbers :
> 
> I guess I'll need to figure out which of these are set by the ./configu
re
> options available for POV-Ray, and how the Intel compiler deals with th
em...
> 
> Thanks for the info.
> 
> 
> 
try a ./configure --enable-debug=full, it should be OK

Post a reply to this message

clipka escreveu:
> Hum... so now I know in which *function* it crashes - but what do I have to do
> in order to get the *line number*??

http://sourceware.org/gdb/current/onlinedocs/gdb_9.html#SEC57

In particular:
"When your program stops, GDB spontaneously prints the line where it 
stopped. Likewise, when you select a stack frame (see section Selecting 
a Frame), GDB prints the line where execution in that frame has stopped. 
You can print other portions of source files by explicit command."

Some commands:
next
step
list linenumber
list functionname

etc

> I knew I wouldn't like debugging under Linux :S

Not really that bad if you RTFM. ;)

I might too that both vim and emacs support fluid integrated interfaces 
to the whole dev stack:  make, gcc and gdb.  Of course, it would need 
you to learn a bit of these very different tools, something not 
happening when you seem reluctant to try even KDevelop and it's VS-like 
workflow...

Post a reply to this message

nemesis escreveu:
errata:
> I might add too

Post a reply to this message

nemesis <nam### [at] gmailcom> wrote:
> > I knew I wouldn't like debugging under Linux :S
>
> Not really that bad if you RTFM. ;)

You know how F those M's are to R if all you want to do is just to figure out
where a program crashed on a Linux system, when otherwise you basically do all
development under windows? ;)

I mean, it's not like they have any "quick start" sections (or I'm R'ing T wrong
FM's...)

Post a reply to this message