|
|
> 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
|
|