It's common on Linux/UNIX to compile with -g -O2. It is usually still
possible to step through the code and examine variables even though the
optimizing compiler does rearrange the code a bit.

Stepping from main down to the seg fault you will find to be impractically
tedious. This is partly because the computer normally whizzes through
simply oodles of code (its only reason for being) so that going a step at a
time takes for EVER, and partly because gdb does not always step when it is
supposed to. In practice you will need to set a breakpoint reasonably close
to where you think the segfault is. But since Csound 5 loads opcodes
dynamically, you need to have them loaded before you can set breakpoints in
them and even then things don't always work that well. (Microsoft is MUCH
better at this!) 

You can try dll-symbol  to pre-load the code and try to set a
breakpoint; this doesn't work too well on Windows but it might work on
Linux. In short, debugging is not easy (especially with gdb), so don't get
frustrated and start thinking you are dumb or it is impossible! Also, if
you are in a function and you can't step as you think you should, set a
breakpoint a few lines ahead on a line you expect to hit -- I pretty much
have to do that all the time.

I would debug in emacs or with Insight too if I were you, seeing the source
all the time does speed things up.

Original Message:
-----------------
From: steven yi stevenyi@csounds.com
Date: Wed, 14 Jul 2004 10:48:43 -0700
To: csound-dev@eartha.mills.edu
Subject: [CSOUND-DEV:4977] RE: Diagnosing Csound5


Hi Michael,

I'm developing on Linux; bt last night didn't tell me much, though now 
that I think of it, I might have compiled csound with -O2 which I think 
obfuscates things for gdb.  I'm going to try using 'where' as suggested 
by John tonight and if not I think I'll place a breakpoint at the 
beginning of the main csound function and just step away until I find 
the segfault.

Thanks for the advice!
steven


gogins@pipeline.com wrote:
> backtrace or bt will print a stack trace. But if you have had a seg fault,
> the stack may be blown away and bt may not tell you anything. In that case
> you should set a breakpoint as close to the seg fault as possible and then
> use the step command to approach the seg fault one line of code at a time.
> 
> You are running on what platform?
> 


--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .

Hi Michael,

Thanks for the advice.  I've gone through csound with gdb from the top 
function call in the past and because of that experience didn't want to 
do that again if I didn't have to.  =)  I didn't know about dll-symbol 
so will look into that if I haven't figured it out before then.  I might 
be able to re-setup the project in my IDE eclipse to make debugging a 
bit more convenient.

Thanks again (everyone!) for passing along the programming wisdom!

steven



gogins@pipeline.com wrote:
> It's common on Linux/UNIX to compile with -g -O2. It is usually still
> possible to step through the code and examine variables even though the
> optimizing compiler does rearrange the code a bit.
> 
> Stepping from main down to the seg fault you will find to be impractically
> tedious. This is partly because the computer normally whizzes through
> simply oodles of code (its only reason for being) so that going a step at a
> time takes for EVER, and partly because gdb does not always step when it is
> supposed to. In practice you will need to set a breakpoint reasonably close
> to where you think the segfault is. But since Csound 5 loads opcodes
> dynamically, you need to have them loaded before you can set breakpoints in
> them and even then things don't always work that well. (Microsoft is MUCH
> better at this!) 
> 
> You can try dll-symbol  to pre-load the code and try to set a
> breakpoint; this doesn't work too well on Windows but it might work on
> Linux. In short, debugging is not easy (especially with gdb), so don't get
> frustrated and start thinking you are dumb or it is impossible! Also, if
> you are in a function and you can't step as you think you should, set a
> breakpoint a few lines ahead on a line you expect to hit -- I pretty much
> have to do that all the time.
> 
> I would debug in emacs or with Insight too if I were you, seeing the source
> all the time does speed things up.
> 

Hi John,

I can't seem to write to the cvs repository,  can you check if 
permissions for me are set correctly? I get the following from cvs:

cvs -d :pserver:mantaraya36@cvs.sourceforge.net:/cvsroot/csound login
Logging in to :pserver:mantaraya36@cvs.sourceforge.net:2401:/cvsroot/csound

***** CVS exited normally with code 0 *****

cvs commit -m "Added vstbload-not yet working. fixed vstinfo to work 
when not called at initial..." vst4cs.cpp vst4cs.h (in directory 
H:\C_Progs\csound5\Opcodes\vst4cs\src)
cvs [server aborted]: "commit" requires write access to the repository

***** CVS exited normally with code 1 *****

It's very probable I'm doing something wrong. Does anyone know if you 
have to do anything different when using winCVS?

Cheers,
Andrés

Hum; I did what the instructions (appeared to) say.  I have given you
access to all csound5 as far as I cam tell.  Let me know of the next problem.
==John ffitch