I think at this point it'd be best to run the project in gdb or lldb
and get a backtrace, or post the CSD and C++ code here.

On Thu, Oct 8, 2015 at 10:10 AM, Peter Burgess
 wrote:
> So we are good to fire away on this new mailing list?
>
> This is a continuation from a discussion in the old list, so if I should
> copy and paste any of the old convo in here for reference let me know.
>
> I am continuing to have issues with a seg fault while compiling a csd that
> compiles fine 80% of the time, but  fails to compile at very specific
> intervals (also it's worth mentioning that the .csd get's rebuild in my c++
> app before each compile. so the score section is slightly different each
> time). I can also compile the problematic files from terminal with no
> problem.
>
> @Victor: I tried using csound.Compile(argc, argv) instead, but to no avail.
> As far as I can tell, it is actually starting to read the .csd file, and
> failing part way through the compilation. I get this readout from the
> terminal:
>
> UnifiedCSD:  csound/CSD/samples.csd
> STARTING FILE
> Creating options
> Csound tidy up: Segmentation fault
> end of score.           overall amps:      0.0
>        overall samples out of range:        0
> 0 errors in performance
>
> Looks to me like it is failing on the options somewhere, but the options are
> always the same besides the wav filename it is exporting to (which aren't

Use te gdb debugger.  If csound was buil with -g (and your code) it s even 
better


On Thu, 8 Oct 2015, Peter Burgess wrote:

> I was just wondering if there's some kind of debugger i can use, so these will
> check csound aswell?
> 
> I will give these a shot. From my investigations, my best guess at the moment
> is that the fstream that is creating the .csd file before compilation hasn't
> quite finished yet before .compile get's called. Is that possible? I would of
> thought the fstream operation gets completed before anything else is executed,
> but I'm struggling to come up with any other ideas!
> 
> On Thu, Oct 8, 2015 at 3:32 PM, Steven Yi  wrote:
>       I think at this point it'd be best to run the project in gdb or
>       lldb
>       and get a backtrace, or post the CSD and C++ code here.

For most IDE's you can set commandline arguments to the executable
being debugged. I know how to do this in XCode, but I don't use
CodeBlocks so I'm not sure how that would be done there.

On Thu, Oct 8, 2015 at 10:55 AM, Peter Burgess
 wrote:
> How do i get it to debug the .csd file? It's already debugging everything
> else. The best I get from it is that it points out that it failed during
> compilation, and points me to the csound.hpp function in which it failed,
> ie, one of these:
>
>  virtual int Compile(int argc, char **argv)
>   {
>     return csoundCompile(csound, argc, argv);      <<--- and points here
>   }
>
> sorry, that was in the old message, probably should have reposted that bit
> too. A weird thing is that if I run my app under the debugger, it gets
> further before crashing, to another exact place in the app.
>
> something I didn't post before was the call stack:
>
> #0 0x7ffff6e67ec3    argdecode() (/usr/local/lib/libcsound64.so.6.0:??)
> #1 0x7ffff6e7866c    readOptions() (/usr/local/lib/libcsound64.so.6.0:??)
> #2 0x7ffff6e7a5ef    read_unified_file()
> (/usr/local/lib/libcsound64.so.6.0:??)
> #3 0x7ffff6e75adc    csoundCompileArgs()
> (/usr/local/lib/libcsound64.so.6.0:??)
> #4 0x7ffff6e76dab    csoundCompile() (/usr/local/lib/libcsound64.so.6.0:??)
> #5 0x40b3ac    Csound::Compile(this=0x6435d0 , argc=2,
> argv=0x7fffffffd990) (csound/Csound6.05/include/csound.hpp:209)
>
> On Thu, Oct 8, 2015 at 3:45 PM, jpff  wrote:
>>
>> Use te gdb debugger.  If csound was buil with -g (and your code) it s even
>> better
>>
>>
>>
>> On Thu, 8 Oct 2015, Peter Burgess wrote:
>>
>>> I was just wondering if there's some kind of debugger i can use, so these
>>> will
>>> check csound aswell?
>>>
>>> I will give these a shot. From my investigations, my best guess at the
>>> moment
>>> is that the fstream that is creating the .csd file before compilation
>>> hasn't
>>> quite finished yet before .compile get's called. Is that possible? I
>>> would of
>>> thought the fstream operation gets completed before anything else is
>>> executed,
>>> but I'm struggling to come up with any other ideas!
>>>
>>> On Thu, Oct 8, 2015 at 3:32 PM, Steven Yi  wrote:
>>>       I think at this point it'd be best to run the project in gdb or
>>>       lldb
>>>       and get a backtrace, or post the CSD and C++ code here.
>>>

Oh, I think I misread this thread.  You're passing the CSD to the
Csound instance in C++, yes?  If so, then just debugging the
executable should be enough. If it was something wrong in an opcode,
and if Csound was built with debug (i.e. using
-DCMAKE_BUILD_TYPE=Debug when building), then the debugger would have
broke at the place in the opcode.

As the last call stack you posted showed it failing in argdecode, it
looks like a problem in Csound before processing the CSD.

I guess two things to do here:

1. Check if Csound is built for debug.  The build type would have been
given as an argument when calling cmake.  You can also check the
CMakeCache.txt in your build directory and search for CMAKE_BUILD_TYPE
and set set to Debug if not already.

2. Post code here that reproduces your problem, and one of us can try
it out locally. It's hard to diagnose without seeing the rest of the
code in context (for me at least.)

On Thu, Oct 8, 2015 at 11:30 AM, Peter Burgess
 wrote:
> what kind of arguements would I need to set?
>
> On Thu, Oct 8, 2015 at 4:00 PM, Steven Yi  wrote:
>>
>> For most IDE's you can set commandline arguments to the executable
>> being debugged. I know how to do this in XCode, but I don't use
>> CodeBlocks so I'm not sure how that would be done there.
>>
>> On Thu, Oct 8, 2015 at 10:55 AM, Peter Burgess
>>  wrote:
>> > How do i get it to debug the .csd file? It's already debugging
>> > everything
>> > else. The best I get from it is that it points out that it failed during
>> > compilation, and points me to the csound.hpp function in which it
>> > failed,
>> > ie, one of these:
>> >
>> >  virtual int Compile(int argc, char **argv)
>> >   {
>> >     return csoundCompile(csound, argc, argv);      <<--- and points here
>> >   }
>> >
>> > sorry, that was in the old message, probably should have reposted that
>> > bit
>> > too. A weird thing is that if I run my app under the debugger, it gets
>> > further before crashing, to another exact place in the app.
>> >
>> > something I didn't post before was the call stack:
>> >
>> > #0 0x7ffff6e67ec3    argdecode() (/usr/local/lib/libcsound64.so.6.0:??)
>> > #1 0x7ffff6e7866c    readOptions()
>> > (/usr/local/lib/libcsound64.so.6.0:??)
>> > #2 0x7ffff6e7a5ef    read_unified_file()
>> > (/usr/local/lib/libcsound64.so.6.0:??)
>> > #3 0x7ffff6e75adc    csoundCompileArgs()
>> > (/usr/local/lib/libcsound64.so.6.0:??)
>> > #4 0x7ffff6e76dab    csoundCompile()
>> > (/usr/local/lib/libcsound64.so.6.0:??)
>> > #5 0x40b3ac    Csound::Compile(this=0x6435d0 , argc=2,
>> > argv=0x7fffffffd990) (csound/Csound6.05/include/csound.hpp:209)
>> >
>> > On Thu, Oct 8, 2015 at 3:45 PM, jpff  wrote:
>> >>
>> >> Use te gdb debugger.  If csound was buil with -g (and your code) it s
>> >> even
>> >> better
>> >>
>> >>
>> >>
>> >> On Thu, 8 Oct 2015, Peter Burgess wrote:
>> >>
>> >>> I was just wondering if there's some kind of debugger i can use, so
>> >>> these
>> >>> will
>> >>> check csound aswell?
>> >>>
>> >>> I will give these a shot. From my investigations, my best guess at the
>> >>> moment
>> >>> is that the fstream that is creating the .csd file before compilation
>> >>> hasn't
>> >>> quite finished yet before .compile get's called. Is that possible? I
>> >>> would of
>> >>> thought the fstream operation gets completed before anything else is
>> >>> executed,
>> >>> but I'm struggling to come up with any other ideas!
>> >>>
>> >>> On Thu, Oct 8, 2015 at 3:32 PM, Steven Yi  wrote:
>> >>>       I think at this point it'd be best to run the project in gdb or
>> >>>       lldb
>> >>>       and get a backtrace, or post the CSD and C++ code here.
>> >>>
>> >
>

That backtrace indicates that your argv or/and argc are wrong.  The 
function argdecode is readung argv looking for arguments starting -
As a guess it is reading an arg that is not a char*.  Notes c++ string 
tyope is not a char* in C

Try looking at argv in your coode before calling compile


On Thu, 8 Oct 2015, Peter Burgess wrote:

> How do i get it to debug the .csd file? It's already debugging everything
> else. The best I get from it is that it points out that it failed during
> compilation, and points me to the csound.hpp function in which it failed, ie,
> one of these:
> 
>  virtual int Compile(int argc, char **argv)
>   {
>     return csoundCompile(csound, argc, argv);      <<--- and points here
>   }
> 
> sorry, that was in the old message, probably should have reposted that bit
> too. A weird thing is that if I run my app under the debugger, it gets further
> before crashing, to another exact place in the app.
> 
> something I didn't post before was the call stack:
> 
> #0 0x7ffff6e67ec3    argdecode() (/usr/local/lib/libcsound64.so.6.0:??)
> #1 0x7ffff6e7866c    readOptions() (/usr/local/lib/libcsound64.so.6.0:??)
> #2 0x7ffff6e7a5ef    read_unified_file()
> (/usr/local/lib/libcsound64.so.6.0:??)
> #3 0x7ffff6e75adc    csoundCompileArgs()
> (/usr/local/lib/libcsound64.so.6.0:??)
> #4 0x7ffff6e76dab    csoundCompile() (/usr/local/lib/libcsound64.so.6.0:??)
> #5 0x40b3ac    Csound::Compile(this=0x6435d0 , argc=2,
> argv=0x7fffffffd990) (csound/Csound6.05/include/csound.hpp:209)
> 
> On Thu, Oct 8, 2015 at 3:45 PM, jpff  wrote:
>       Use te gdb debugger.  If csound was buil with -g (and your code)
>       it s even better
> 
>
>       On Thu, 8 Oct 2015, Peter Burgess wrote:
>
>             I was just wondering if there's some kind of debugger
>             i can use, so these will
>             check csound aswell?
>
>             I will give these a shot. From my investigations, my
>             best guess at the moment
>             is that the fstream that is creating the .csd file
>             before compilation hasn't
>             quite finished yet before .compile get's called. Is
>             that possible? I would of
>             thought the fstream operation gets completed before
>             anything else is executed,
>             but I'm struggling to come up with any other ideas!
>
>             On Thu, Oct 8, 2015 at 3:32 PM, Steven Yi
>              wrote:
>                   I think at this point it'd be best to run the
>             project in gdb or
>                   lldb
>                   and get a backtrace, or post the CSD and C++
>             code here.
> 
> 
> 
>

Another thought -- can you try
 	result = csound.Compile(2, argv);

There is a curious comment in the argdecode function that implies argc as 
been decremented already
./Top/argdecode.c:    /* N.B. the argc value passed to argdecode is 
decremented by one */

Not chased this yet --  only a wild thought.  I am ratherc==-adverse


On Thu, 8 Oct 2015, Peter Burgess wrote:

> They should be char*, currently reads like this:
> 
> void exportWav (char* csdFileName) {
> 
>     // Compile csd
>     int result = -1;
>     char* argv[] = {"Csound", csdFileName, "-v"};
>     while (result != 0) {
>         cout << "Trying to compile csound!" << endl;
>         result = csound.Compile(3, argv);
>     }
>     // Perform score
>     if (!result) {
>         while (csound.Perform() == 0) {}
>     }
>     else
>         cout << "Csound compilation failed!!!" << endl;
>     // Free Csound
>     csound.Reset();
> }
> 
> though mike did mention something about a different way of setting strings as
> char* in the old post. I should go look at that again
> 
> On Thu, Oct 8, 2015 at 5:10 PM, Peter Burgess 
> wrote:
>       You know I gave that a whirl earlier after reading it in an old
>       mailing list post, but I stuck it in the .csd options section, and
>       it gave no info (presumably because it didn't open the file). It
>       just occured to me after reading your post, that I can send it as
>       an arguement with csound.compile so it knows i want that option
>       before reading the .csd. It has given me slightly more info,
>       though I'm still not sure it's much to go on...
>
>       UnifiedCSD:  csound/CSD/samples.csd
>       Environment variable 'SADIR' has been set to
>       '/home/pete/Documents/CsoundProjectGUI/csound/CSD'
>       Environment variable 'SSDIR' has been set to
>       '/home/pete/Documents/CsoundProjectGUI/csound/CSD'
>       Environment variable 'INCDIR' has been set to
>       '/home/pete/Documents/CsoundProjectGUI/csound/CSD'
>       Environment variable 'MFDIR' has been set to
>       '/home/pete/Documents/CsoundProjectGUI/csound/CSD'
>       STARTING FILE
>       Creating options
>       Csound tidy up: Segmentation fault
> 
> On Thu, Oct 8, 2015 at 4:57 PM, jpff  wrote:
>       You can get more information with the -v option to csound
> 
> 
> 
> 
>

strdup duplicates a string (memory pointed to be char * that ends with
a null character). The caller is responsible for deallocating the
memory. My theory was that something was deallocating your arguments
before you tried to read them, this would solve that at the cost of a
modest memory leak. But I don't actually think this is the problem.

I suggest you print out, in your program, in this order, for each arg
in argv: (1) the index of the arg; (2) the value in hex of the pointer
for each element of agrv. If there is a bad pointer it might have a
funny bit pattern like "0xbaadf00d" or something, written by the
debugger heap, see
http://stackoverflow.com/questions/127386/in-visual-studio-c-what-are-the-memory-allocation-representations;
(3) the first 20 bytes of the memory pointed to by the pointer. If the
args are wrong or messed up this should show where and what. Of course
you can do this in the debugger by hand by printing the memory pointed
by by argv[0], argv[1], etc.

Regards,
Mike


-----------------------------------------------------
Michael Gogins
Irreducible Productions
http://michaelgogins.tumblr.com
Michael dot Gogins at gmail dot com


On Thu, Oct 8, 2015 at 1:42 PM, Peter Burgess
 wrote:
> changing it to 2 just loses the -v arguement and it runs as normal again.
> Out of curiosity, I changed it to 4 as well, lol. Instant failure, not sure
> what I really expected that would achieve!
>
> I've had a look at where i can use strdup, but I'm not sure where it would
> help. Tried it here...
>
> char* argv[] = {"Csound", strdup(csdFileName), "-v"};
>
> feels sort of redundent though. I'm not sure though, not entirely sure what
> strdup does. Also having looked through, my filepath starts life as a char*,
> don't know if that's relevant either, but i thought it worth noting that I
> don't convert it from a string.
>
> Still, this problem only occurs some of the time, and at fixed intervals.
> The fault also delays slightly, in an equally fixed manor, when running
> under the debugger...  It's very weird!
>
> I feel like I'm running out of options here, can only think my next task is
> to go through my whole program and cut bits out until the problem goes away.
> It's a huge program too :S at least it seems huge to me. That'll teach me to
> not sort out the bug as soon as i noticed it, doh! I would send someone the
> files to reproduce the error, but as I said, it's a big project, and to cut
> it down enough to send it out with the bug intact would probably require me
> to locate the bug anyway :D
>
> Thank you all very much for your help guys! If anyone else thinks of
> anything let me know, otherwise, I'll tell you how it goes.
>
> Pete
>
> On Thu, Oct 8, 2015 at 5:31 PM, jpff  wrote:
>>
>> Another thought -- can you try
>>         result = csound.Compile(2, argv);
>>
>> There is a curious comment in the argdecode function that implies argc as
>> been decremented already
>> ./Top/argdecode.c:    /* N.B. the argc value passed to argdecode is
>> decremented by one */
>>
>> Not chased this yet --  only a wild thought.  I am ratherc==-adverse
>>
>>
>> On Thu, 8 Oct 2015, Peter Burgess wrote:
>>
>>> They should be char*, currently reads like this:
>>>
>>> void exportWav (char* csdFileName) {
>>>
>>>     // Compile csd
>>>     int result = -1;
>>>     char* argv[] = {"Csound", csdFileName, "-v"};
>>>     while (result != 0) {
>>>         cout << "Trying to compile csound!" << endl;
>>>         result = csound.Compile(3, argv);
>>>     }
>>>     // Perform score
>>>     if (!result) {
>>>         while (csound.Perform() == 0) {}
>>>     }
>>>     else
>>>         cout << "Csound compilation failed!!!" << endl;
>>>     // Free Csound
>>>     csound.Reset();
>>> }
>>>
>>> though mike did mention something about a different way of setting
>>> strings as
>>> char* in the old post. I should go look at that again
>>>
>>> On Thu, Oct 8, 2015 at 5:10 PM, Peter Burgess
>>> 
>>> wrote:
>>>       You know I gave that a whirl earlier after reading it in an old
>>>       mailing list post, but I stuck it in the .csd options section, and
>>>       it gave no info (presumably because it didn't open the file). It
>>>       just occured to me after reading your post, that I can send it as
>>>       an arguement with csound.compile so it knows i want that option
>>>       before reading the .csd. It has given me slightly more info,
>>>       though I'm still not sure it's much to go on...
>>>
>>>       UnifiedCSD:  csound/CSD/samples.csd
>>>       Environment variable 'SADIR' has been set to
>>>       '/home/pete/Documents/CsoundProjectGUI/csound/CSD'
>>>       Environment variable 'SSDIR' has been set to
>>>       '/home/pete/Documents/CsoundProjectGUI/csound/CSD'
>>>       Environment variable 'INCDIR' has been set to
>>>       '/home/pete/Documents/CsoundProjectGUI/csound/CSD'
>>>       Environment variable 'MFDIR' has been set to
>>>       '/home/pete/Documents/CsoundProjectGUI/csound/CSD'
>>>       STARTING FILE
>>>       Creating options
>>>       Csound tidy up: Segmentation fault
>>>
>>> On Thu, Oct 8, 2015 at 4:57 PM, jpff  wrote:
>>>       You can get more information with the -v option to csound
>>>
>>>
>>>
>>>