> 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