Hi All,

I'm working on debugging some crashes with csound~ on Windows.  So
far, I've found crashes with two of the examples that had come with
Davis's installer:

=============================

-vocoder.maxpat

I get a strange error in GDB:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 2944.0x290]
vco2set (csound=0xe0c89f8, p=0xe2b05a8)
    at c:/Users/Administrator/work/csound6/Opcodes/oscbnk.c:1950
1950        int     tnums[8] = { 0, 0, 1, 2, 1, 3, 4, 5 };
(gdb) bt
#0  vco2set (csound=0xe0c89f8, p=0xe2b05a8)
    at c:/Users/Administrator/work/csound6/Opcodes/oscbnk.c:1950
#1  0x6c51295a in insert (csound=csound@entry=0xe0c89f8, insno=insno@entry=1,
    newevtp=newevtp@entry=0xe0cbbb0)
    at c:/Users/Administrator/work/csound6/Engine/insert.c:273
#2  0x6c517d39 in process_score_event (csound=csound@entry=0xe0c89f8,
    evt=evt@entry=0xe0cbbb0, rtEvt=rtEvt@entry=0)
    at c:/Users/Administrator/work/csound6/Engine/musmon.c:757
#3  0x6c51a49b in sensevents (csound=csound@entry=0xe0c89f8)
    at c:/Users/Administrator/work/csound6/Engine/musmon.c:946

=============================

-pluckSynth.max.pat

(gdb) bt
#0  0x6c6c1949 in create_instrument0 (csound=csound@entry=0xa90b270,
    root=root@entry=0xa9acab8, engineState=engineState@entry=0xa90b718,
    varPool=0x9e2b758)
    at c:/Users/Administrator/work/csound6/Engine/csound_orc_compile.c:505
#1  0x6c6c320e in csoundCompileTree (csound=csound@entry=0xa90b270,
    root=root@entry=0xa9efaf8)
    at c:/Users/Administrator/work/csound6/Engine/csound_orc_compile.c:1394
#2  0x6c6c372c in csoundCompileOrc (csound=csound@entry=0xa90b270,
    str=str@entry=0x0)
    at c:/Users/Administrator/work/csound6/Engine/csound_orc_compile.c:1679
#3  0x6c61e81a in csoundCompileArgs (csound=csound@entry=0xa90b270, argc=5,
    argc@entry=6, argv=argv@entry=0xa90b01c)
    at c:/Users/Administrator/work/csound6/Top/main.c:234
#4  0x6c61f6b0 in csoundCompile (csound=0xa90b270, argc=6, argv=0xa90b01c)
    at c:/Users/Administrator/work/csound6/Top/main.c:490
#5  0x6224a2c4 in dvx::CsoundObject::Compile (this=0xa905f58, lock=true)
    at c:/Users/Administrator/work/csound6/frontends/max_csound_tilde/src/Cs
Object.cpp:191
#6  0x62249f91 in dvx::CsoundObject::Compile (this=0xa905f58)
    at c:/Users/Administrator/work/csound6/frontends/max_csound_tilde/src/Cs
Object.cpp:95
#7  0x62247b37 in csound_startDeferred (x=0x3e732f0)
    at c:/Users/Administrator/work/csound6/frontends/max_csound_tilde/src/cs
~.cpp:794
#8  0x62247974 in csound_new (s=0x3a18eb8, argc=4, argv=0x11cdb36)
    at c:/Users/Administrator/work/csound6/frontends/max_csound_tilde/src/cs
~.cpp:755
#9  0x007921bb in getfn ()
#10 0x011cdb36 in ?? ()
#11 0x00788a8c in object_dictionary_fromnewargs ()
#12 0x011cd760 in ?? ()
#13 0x000305fc in ?? ()
Cannot access memory at address 0xbfec0007

again this is a weird one as it's crashing on a line that's setting
some local variables to the function.

=============================

I've compiled Csound with mingw (32-bit), with
-DCMAKE_BUILD_TYPE=Debug.  To debug, I'm using"

gdb /c/Program\ Files\ \(x86\)/Cycling\ \'74/Max\ Runtime\ 6.1/MaxRT.exe

I can run the csd's for those patches from the commandline using
csound without a crash. Also, there is no other installation of Csound
besides the one I compiled.

It's an odd error for both of the above, so I'm a little stumped at
the moment. I suspect the bug is elsewhere and that gdb is just
getting confused.  If anyone has some suggestions or has time to work
along here that'd be great.

Thanks!
steven

------------------------------------------------------------------------------
Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works. 
Faster operations. Version large binaries.  Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Hi Michael,

Thanks for the email.  I had been doing most of what you had
recommended already. The one thing that you mentioned that was very
useful was the optimization thing. I forgot that the Custom.cmake had
-O3 in it, which essentially make using CMAKE_BUILD_TYPE useless.
(That flag being there has messed me up so many times now that I've
removed it from the Custom.cmake.ex).

Interestingly, with the debug build (without -O3), I did not get
crashes (yay!). I did pull in some changes from develop branch between
when I was testing and when I did this latest build, so I don't know
yet if it is the change in optimization flag or if it was something
fixed in develop. I'm rebuilding with -DCMAKE_RELEASE_TYPE=Release now
and will retest with that.

Thanks!
steven

On Thu, Mar 6, 2014 at 11:01 AM, Michael Gogins
 wrote:
> GDB can jump around, especially if you are debugging optimized code (O2 or
> O3).
>
> I suggest you set a breakpoint ahead of the crash, then step through the
> code. It's often faster to put in print statements on suspect pointers,
> data, etc. rather than manually inspecting them in gdb.
>
> Keep in mind when stepping, that with optimized code, GDB will appear to
> enter a function or block of code more than once, jumping back to "run it
> for real" after a bit.
>
> Also, is something happening in a different thread first, corrupting data
> that then causes this crash?
>
> Hope this helps,
> Mike
>
> Hope this helps,
> Mike
>
>
>
>
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com
>
>
> On Thu, Mar 6, 2014 at 10:45 AM, Steven Yi  wrote:
>>
>> Hi All,
>>
>> I'm working on debugging some crashes with csound~ on Windows.  So
>> far, I've found crashes with two of the examples that had come with
>> Davis's installer:
>>
>> =============================
>>
>> -vocoder.maxpat
>>
>> I get a strange error in GDB:
>>
>> Program received signal SIGSEGV, Segmentation fault.
>> [Switching to Thread 2944.0x290]
>> vco2set (csound=0xe0c89f8, p=0xe2b05a8)
>>     at c:/Users/Administrator/work/csound6/Opcodes/oscbnk.c:1950
>> 1950        int     tnums[8] = { 0, 0, 1, 2, 1, 3, 4, 5 };
>> (gdb) bt
>> #0  vco2set (csound=0xe0c89f8, p=0xe2b05a8)
>>     at c:/Users/Administrator/work/csound6/Opcodes/oscbnk.c:1950
>> #1  0x6c51295a in insert (csound=csound@entry=0xe0c89f8,
>> insno=insno@entry=1,
>>     newevtp=newevtp@entry=0xe0cbbb0)
>>     at c:/Users/Administrator/work/csound6/Engine/insert.c:273
>> #2  0x6c517d39 in process_score_event (csound=csound@entry=0xe0c89f8,
>>     evt=evt@entry=0xe0cbbb0, rtEvt=rtEvt@entry=0)
>>     at c:/Users/Administrator/work/csound6/Engine/musmon.c:757
>> #3  0x6c51a49b in sensevents (csound=csound@entry=0xe0c89f8)
>>     at c:/Users/Administrator/work/csound6/Engine/musmon.c:946
>>
>> =============================
>>
>> -pluckSynth.max.pat
>>
>> (gdb) bt
>> #0  0x6c6c1949 in create_instrument0 (csound=csound@entry=0xa90b270,
>>     root=root@entry=0xa9acab8, engineState=engineState@entry=0xa90b718,
>>     varPool=0x9e2b758)
>>     at c:/Users/Administrator/work/csound6/Engine/csound_orc_compile.c:505
>> #1  0x6c6c320e in csoundCompileTree (csound=csound@entry=0xa90b270,
>>     root=root@entry=0xa9efaf8)
>>     at
>> c:/Users/Administrator/work/csound6/Engine/csound_orc_compile.c:1394
>> #2  0x6c6c372c in csoundCompileOrc (csound=csound@entry=0xa90b270,
>>     str=str@entry=0x0)
>>     at
>> c:/Users/Administrator/work/csound6/Engine/csound_orc_compile.c:1679
>> #3  0x6c61e81a in csoundCompileArgs (csound=csound@entry=0xa90b270,
>> argc=5,
>>     argc@entry=6, argv=argv@entry=0xa90b01c)
>>     at c:/Users/Administrator/work/csound6/Top/main.c:234
>> #4  0x6c61f6b0 in csoundCompile (csound=0xa90b270, argc=6, argv=0xa90b01c)
>>     at c:/Users/Administrator/work/csound6/Top/main.c:490
>> #5  0x6224a2c4 in dvx::CsoundObject::Compile (this=0xa905f58, lock=true)
>>     at
>> c:/Users/Administrator/work/csound6/frontends/max_csound_tilde/src/Cs
>> Object.cpp:191
>> #6  0x62249f91 in dvx::CsoundObject::Compile (this=0xa905f58)
>>     at
>> c:/Users/Administrator/work/csound6/frontends/max_csound_tilde/src/Cs
>> Object.cpp:95
>> #7  0x62247b37 in csound_startDeferred (x=0x3e732f0)
>>     at
>> c:/Users/Administrator/work/csound6/frontends/max_csound_tilde/src/cs
>> ~.cpp:794
>> #8  0x62247974 in csound_new (s=0x3a18eb8, argc=4, argv=0x11cdb36)
>>     at
>> c:/Users/Administrator/work/csound6/frontends/max_csound_tilde/src/cs
>> ~.cpp:755
>> #9  0x007921bb in getfn ()
>> #10 0x011cdb36 in ?? ()
>> #11 0x00788a8c in object_dictionary_fromnewargs ()
>> #12 0x011cd760 in ?? ()
>> #13 0x000305fc in ?? ()
>> Cannot access memory at address 0xbfec0007
>>
>> again this is a weird one as it's crashing on a line that's setting
>> some local variables to the function.
>>
>> =============================
>>
>> I've compiled Csound with mingw (32-bit), with
>> -DCMAKE_BUILD_TYPE=Debug.  To debug, I'm using"
>>
>> gdb /c/Program\ Files\ \(x86\)/Cycling\ \'74/Max\ Runtime\ 6.1/MaxRT.exe
>>
>> I can run the csd's for those patches from the commandline using
>> csound without a crash. Also, there is no other installation of Csound
>> besides the one I compiled.
>>
>> It's an odd error for both of the above, so I'm a little stumped at
>> the moment. I suspect the bug is elsewhere and that gdb is just
>> getting confused.  If anyone has some suggestions or has time to work
>> along here that'd be great.
>>
>> Thanks!
>> steven
>>
>>
>> ------------------------------------------------------------------------------
>> Subversion Kills Productivity. Get off Subversion & Make the Move to
>> Perforce.
>> With Perforce, you get hassle-free workflows. Merge that actually works.
>> Faster operations. Version large binaries.  Built-in WAN optimization and
>> the
>> freedom to use Git, Perforce or both. Make the move to Perforce.
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>
> ------------------------------------------------------------------------------
> Subversion Kills Productivity. Get off Subversion & Make the Move to
> Perforce.
> With Perforce, you get hassle-free workflows. Merge that actually works.
> Faster operations. Version large binaries.  Built-in WAN optimization and
> the
> freedom to use Git, Perforce or both. Make the move to Perforce.
> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

------------------------------------------------------------------------------
Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works. 
Faster operations. Version large binaries.  Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Update: Using Release build type (which uses -O3), I get the crash.
At least that's a start for figuring this out.  I'll probably try an
-O2 build tomorrow to see if that work.

On Thu, Mar 6, 2014 at 11:32 AM, Steven Yi  wrote:
> Hi Michael,
>
> Thanks for the email.  I had been doing most of what you had
> recommended already. The one thing that you mentioned that was very
> useful was the optimization thing. I forgot that the Custom.cmake had
> -O3 in it, which essentially make using CMAKE_BUILD_TYPE useless.
> (That flag being there has messed me up so many times now that I've
> removed it from the Custom.cmake.ex).
>
> Interestingly, with the debug build (without -O3), I did not get
> crashes (yay!). I did pull in some changes from develop branch between
> when I was testing and when I did this latest build, so I don't know
> yet if it is the change in optimization flag or if it was something
> fixed in develop. I'm rebuilding with -DCMAKE_RELEASE_TYPE=Release now
> and will retest with that.
>
> Thanks!
> steven
>
> On Thu, Mar 6, 2014 at 11:01 AM, Michael Gogins
>  wrote:
>> GDB can jump around, especially if you are debugging optimized code (O2 or
>> O3).
>>
>> I suggest you set a breakpoint ahead of the crash, then step through the
>> code. It's often faster to put in print statements on suspect pointers,
>> data, etc. rather than manually inspecting them in gdb.
>>
>> Keep in mind when stepping, that with optimized code, GDB will appear to
>> enter a function or block of code more than once, jumping back to "run it
>> for real" after a bit.
>>
>> Also, is something happening in a different thread first, corrupting data
>> that then causes this crash?
>>
>> Hope this helps,
>> Mike
>>
>> Hope this helps,
>> Mike
>>
>>
>>
>>
>> -----------------------------------------------------
>> Michael Gogins
>> Irreducible Productions
>> http://michaelgogins.tumblr.com
>> Michael dot Gogins at gmail dot com
>>
>>
>> On Thu, Mar 6, 2014 at 10:45 AM, Steven Yi  wrote:
>>>
>>> Hi All,
>>>
>>> I'm working on debugging some crashes with csound~ on Windows.  So
>>> far, I've found crashes with two of the examples that had come with
>>> Davis's installer:
>>>
>>> =============================
>>>
>>> -vocoder.maxpat
>>>
>>> I get a strange error in GDB:
>>>
>>> Program received signal SIGSEGV, Segmentation fault.
>>> [Switching to Thread 2944.0x290]
>>> vco2set (csound=0xe0c89f8, p=0xe2b05a8)
>>>     at c:/Users/Administrator/work/csound6/Opcodes/oscbnk.c:1950
>>> 1950        int     tnums[8] = { 0, 0, 1, 2, 1, 3, 4, 5 };
>>> (gdb) bt
>>> #0  vco2set (csound=0xe0c89f8, p=0xe2b05a8)
>>>     at c:/Users/Administrator/work/csound6/Opcodes/oscbnk.c:1950
>>> #1  0x6c51295a in insert (csound=csound@entry=0xe0c89f8,
>>> insno=insno@entry=1,
>>>     newevtp=newevtp@entry=0xe0cbbb0)
>>>     at c:/Users/Administrator/work/csound6/Engine/insert.c:273
>>> #2  0x6c517d39 in process_score_event (csound=csound@entry=0xe0c89f8,
>>>     evt=evt@entry=0xe0cbbb0, rtEvt=rtEvt@entry=0)
>>>     at c:/Users/Administrator/work/csound6/Engine/musmon.c:757
>>> #3  0x6c51a49b in sensevents (csound=csound@entry=0xe0c89f8)
>>>     at c:/Users/Administrator/work/csound6/Engine/musmon.c:946
>>>
>>> =============================
>>>
>>> -pluckSynth.max.pat
>>>
>>> (gdb) bt
>>> #0  0x6c6c1949 in create_instrument0 (csound=csound@entry=0xa90b270,
>>>     root=root@entry=0xa9acab8, engineState=engineState@entry=0xa90b718,
>>>     varPool=0x9e2b758)
>>>     at c:/Users/Administrator/work/csound6/Engine/csound_orc_compile.c:505
>>> #1  0x6c6c320e in csoundCompileTree (csound=csound@entry=0xa90b270,
>>>     root=root@entry=0xa9efaf8)
>>>     at
>>> c:/Users/Administrator/work/csound6/Engine/csound_orc_compile.c:1394
>>> #2  0x6c6c372c in csoundCompileOrc (csound=csound@entry=0xa90b270,
>>>     str=str@entry=0x0)
>>>     at
>>> c:/Users/Administrator/work/csound6/Engine/csound_orc_compile.c:1679
>>> #3  0x6c61e81a in csoundCompileArgs (csound=csound@entry=0xa90b270,
>>> argc=5,
>>>     argc@entry=6, argv=argv@entry=0xa90b01c)
>>>     at c:/Users/Administrator/work/csound6/Top/main.c:234
>>> #4  0x6c61f6b0 in csoundCompile (csound=0xa90b270, argc=6, argv=0xa90b01c)
>>>     at c:/Users/Administrator/work/csound6/Top/main.c:490
>>> #5  0x6224a2c4 in dvx::CsoundObject::Compile (this=0xa905f58, lock=true)
>>>     at
>>> c:/Users/Administrator/work/csound6/frontends/max_csound_tilde/src/Cs
>>> Object.cpp:191
>>> #6  0x62249f91 in dvx::CsoundObject::Compile (this=0xa905f58)
>>>     at
>>> c:/Users/Administrator/work/csound6/frontends/max_csound_tilde/src/Cs
>>> Object.cpp:95
>>> #7  0x62247b37 in csound_startDeferred (x=0x3e732f0)
>>>     at
>>> c:/Users/Administrator/work/csound6/frontends/max_csound_tilde/src/cs
>>> ~.cpp:794
>>> #8  0x62247974 in csound_new (s=0x3a18eb8, argc=4, argv=0x11cdb36)
>>>     at
>>> c:/Users/Administrator/work/csound6/frontends/max_csound_tilde/src/cs
>>> ~.cpp:755
>>> #9  0x007921bb in getfn ()
>>> #10 0x011cdb36 in ?? ()
>>> #11 0x00788a8c in object_dictionary_fromnewargs ()
>>> #12 0x011cd760 in ?? ()
>>> #13 0x000305fc in ?? ()
>>> Cannot access memory at address 0xbfec0007
>>>
>>> again this is a weird one as it's crashing on a line that's setting
>>> some local variables to the function.
>>>
>>> =============================
>>>
>>> I've compiled Csound with mingw (32-bit), with
>>> -DCMAKE_BUILD_TYPE=Debug.  To debug, I'm using"
>>>
>>> gdb /c/Program\ Files\ \(x86\)/Cycling\ \'74/Max\ Runtime\ 6.1/MaxRT.exe
>>>
>>> I can run the csd's for those patches from the commandline using
>>> csound without a crash. Also, there is no other installation of Csound
>>> besides the one I compiled.
>>>
>>> It's an odd error for both of the above, so I'm a little stumped at
>>> the moment. I suspect the bug is elsewhere and that gdb is just
>>> getting confused.  If anyone has some suggestions or has time to work
>>> along here that'd be great.
>>>
>>> Thanks!
>>> steven
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Subversion Kills Productivity. Get off Subversion & Make the Move to
>>> Perforce.
>>> With Perforce, you get hassle-free workflows. Merge that actually works.
>>> Faster operations. Version large binaries.  Built-in WAN optimization and
>>> the
>>> freedom to use Git, Perforce or both. Make the move to Perforce.
>>>
>>> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Subversion Kills Productivity. Get off Subversion & Make the Move to
>> Perforce.
>> With Perforce, you get hassle-free workflows. Merge that actually works.
>> Faster operations. Version large binaries.  Built-in WAN optimization and
>> the
>> freedom to use Git, Perforce or both. Make the move to Perforce.
>> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>

------------------------------------------------------------------------------
Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works. 
Faster operations. Version large binaries.  Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Those flags (-O2 -g) correspond to -DCMAKE_BUILD_TYPE=RelWithDebInfo.
Unfortunately, I tried building with that and still got crashes.

Question: are you using RelWithDebInfo when doing your releases?  If
so, I want to make sure I'm matching up my build for testing here with
what settings you have.

Thanks!

On Thu, Mar 6, 2014 at 12:27 PM, Michael Gogins
 wrote:
> Rather than maintain separate debug and release builds, I prefer to build
> only with -O2 -g. It is possible to debug with O2 and I rarely have found a
> significant speed advantage with O3.
>
> Best,
> Mike
>
>
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com
>
>
> On Thu, Mar 6, 2014 at 11:41 AM, Steven Yi  wrote:
>>
>> Update: Using Release build type (which uses -O3), I get the crash.
>> At least that's a start for figuring this out.  I'll probably try an
>> -O2 build tomorrow to see if that work.
>>
>> On Thu, Mar 6, 2014 at 11:32 AM, Steven Yi  wrote:
>> > Hi Michael,
>> >
>> > Thanks for the email.  I had been doing most of what you had
>> > recommended already. The one thing that you mentioned that was very
>> > useful was the optimization thing. I forgot that the Custom.cmake had
>> > -O3 in it, which essentially make using CMAKE_BUILD_TYPE useless.
>> > (That flag being there has messed me up so many times now that I've
>> > removed it from the Custom.cmake.ex).
>> >
>> > Interestingly, with the debug build (without -O3), I did not get
>> > crashes (yay!). I did pull in some changes from develop branch between
>> > when I was testing and when I did this latest build, so I don't know
>> > yet if it is the change in optimization flag or if it was something
>> > fixed in develop. I'm rebuilding with -DCMAKE_RELEASE_TYPE=Release now
>> > and will retest with that.
>> >
>> > Thanks!
>> > steven
>> >
>> > On Thu, Mar 6, 2014 at 11:01 AM, Michael Gogins
>> >  wrote:
>> >> GDB can jump around, especially if you are debugging optimized code (O2
>> >> or
>> >> O3).
>> >>
>> >> I suggest you set a breakpoint ahead of the crash, then step through
>> >> the
>> >> code. It's often faster to put in print statements on suspect pointers,
>> >> data, etc. rather than manually inspecting them in gdb.
>> >>
>> >> Keep in mind when stepping, that with optimized code, GDB will appear
>> >> to
>> >> enter a function or block of code more than once, jumping back to "run
>> >> it
>> >> for real" after a bit.
>> >>
>> >> Also, is something happening in a different thread first, corrupting
>> >> data
>> >> that then causes this crash?
>> >>
>> >> Hope this helps,
>> >> Mike
>> >>
>> >> Hope this helps,
>> >> Mike
>> >>
>> >>
>> >>
>> >>
>> >> -----------------------------------------------------
>> >> Michael Gogins
>> >> Irreducible Productions
>> >> http://michaelgogins.tumblr.com
>> >> Michael dot Gogins at gmail dot com
>> >>
>> >>
>> >> On Thu, Mar 6, 2014 at 10:45 AM, Steven Yi  wrote:
>> >>>
>> >>> Hi All,
>> >>>
>> >>> I'm working on debugging some crashes with csound~ on Windows.  So
>> >>> far, I've found crashes with two of the examples that had come with
>> >>> Davis's installer:
>> >>>
>> >>> =============================
>> >>>
>> >>> -vocoder.maxpat
>> >>>
>> >>> I get a strange error in GDB:
>> >>>
>> >>> Program received signal SIGSEGV, Segmentation fault.
>> >>> [Switching to Thread 2944.0x290]
>> >>> vco2set (csound=0xe0c89f8, p=0xe2b05a8)
>> >>>     at c:/Users/Administrator/work/csound6/Opcodes/oscbnk.c:1950
>> >>> 1950        int     tnums[8] = { 0, 0, 1, 2, 1, 3, 4, 5 };
>> >>> (gdb) bt
>> >>> #0  vco2set (csound=0xe0c89f8, p=0xe2b05a8)
>> >>>     at c:/Users/Administrator/work/csound6/Opcodes/oscbnk.c:1950
>> >>> #1  0x6c51295a in insert (csound=csound@entry=0xe0c89f8,
>> >>> insno=insno@entry=1,
>> >>>     newevtp=newevtp@entry=0xe0cbbb0)
>> >>>     at c:/Users/Administrator/work/csound6/Engine/insert.c:273
>> >>> #2  0x6c517d39 in process_score_event (csound=csound@entry=0xe0c89f8,
>> >>>     evt=evt@entry=0xe0cbbb0, rtEvt=rtEvt@entry=0)
>> >>>     at c:/Users/Administrator/work/csound6/Engine/musmon.c:757
>> >>> #3  0x6c51a49b in sensevents (csound=csound@entry=0xe0c89f8)
>> >>>     at c:/Users/Administrator/work/csound6/Engine/musmon.c:946
>> >>>
>> >>> =============================
>> >>>
>> >>> -pluckSynth.max.pat
>> >>>
>> >>> (gdb) bt
>> >>> #0  0x6c6c1949 in create_instrument0 (csound=csound@entry=0xa90b270,
>> >>>     root=root@entry=0xa9acab8,
>> >>> engineState=engineState@entry=0xa90b718,
>> >>>     varPool=0x9e2b758)
>> >>>     at
>> >>> c:/Users/Administrator/work/csound6/Engine/csound_orc_compile.c:505
>> >>> #1  0x6c6c320e in csoundCompileTree (csound=csound@entry=0xa90b270,
>> >>>     root=root@entry=0xa9efaf8)
>> >>>     at
>> >>> c:/Users/Administrator/work/csound6/Engine/csound_orc_compile.c:1394
>> >>> #2  0x6c6c372c in csoundCompileOrc (csound=csound@entry=0xa90b270,
>> >>>     str=str@entry=0x0)
>> >>>     at
>> >>> c:/Users/Administrator/work/csound6/Engine/csound_orc_compile.c:1679
>> >>> #3  0x6c61e81a in csoundCompileArgs (csound=csound@entry=0xa90b270,
>> >>> argc=5,
>> >>>     argc@entry=6, argv=argv@entry=0xa90b01c)
>> >>>     at c:/Users/Administrator/work/csound6/Top/main.c:234
>> >>> #4  0x6c61f6b0 in csoundCompile (csound=0xa90b270, argc=6,
>> >>> argv=0xa90b01c)
>> >>>     at c:/Users/Administrator/work/csound6/Top/main.c:490
>> >>> #5  0x6224a2c4 in dvx::CsoundObject::Compile (this=0xa905f58,
>> >>> lock=true)
>> >>>     at
>> >>> c:/Users/Administrator/work/csound6/frontends/max_csound_tilde/src/Cs
>> >>> Object.cpp:191
>> >>> #6  0x62249f91 in dvx::CsoundObject::Compile (this=0xa905f58)
>> >>>     at
>> >>> c:/Users/Administrator/work/csound6/frontends/max_csound_tilde/src/Cs
>> >>> Object.cpp:95
>> >>> #7  0x62247b37 in csound_startDeferred (x=0x3e732f0)
>> >>>     at
>> >>> c:/Users/Administrator/work/csound6/frontends/max_csound_tilde/src/cs
>> >>> ~.cpp:794
>> >>> #8  0x62247974 in csound_new (s=0x3a18eb8, argc=4, argv=0x11cdb36)
>> >>>     at
>> >>> c:/Users/Administrator/work/csound6/frontends/max_csound_tilde/src/cs
>> >>> ~.cpp:755
>> >>> #9  0x007921bb in getfn ()
>> >>> #10 0x011cdb36 in ?? ()
>> >>> #11 0x00788a8c in object_dictionary_fromnewargs ()
>> >>> #12 0x011cd760 in ?? ()
>> >>> #13 0x000305fc in ?? ()
>> >>> Cannot access memory at address 0xbfec0007
>> >>>
>> >>> again this is a weird one as it's crashing on a line that's setting
>> >>> some local variables to the function.
>> >>>
>> >>> =============================
>> >>>
>> >>> I've compiled Csound with mingw (32-bit), with
>> >>> -DCMAKE_BUILD_TYPE=Debug.  To debug, I'm using"
>> >>>
>> >>> gdb /c/Program\ Files\ \(x86\)/Cycling\ \'74/Max\ Runtime\
>> >>> 6.1/MaxRT.exe
>> >>>
>> >>> I can run the csd's for those patches from the commandline using
>> >>> csound without a crash. Also, there is no other installation of Csound
>> >>> besides the one I compiled.
>> >>>
>> >>> It's an odd error for both of the above, so I'm a little stumped at
>> >>> the moment. I suspect the bug is elsewhere and that gdb is just
>> >>> getting confused.  If anyone has some suggestions or has time to work
>> >>> along here that'd be great.
>> >>>
>> >>> Thanks!
>> >>> steven
>> >>>
>> >>>
>> >>>
>> >>> ------------------------------------------------------------------------------
>> >>> Subversion Kills Productivity. Get off Subversion & Make the Move to
>> >>> Perforce.
>> >>> With Perforce, you get hassle-free workflows. Merge that actually
>> >>> works.
>> >>> Faster operations. Version large binaries.  Built-in WAN optimization
>> >>> and
>> >>> the
>> >>> freedom to use Git, Perforce or both. Make the move to Perforce.
>> >>>
>> >>>
>> >>> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
>> >>> _______________________________________________
>> >>> Csound-devel mailing list
>> >>> Csound-devel@lists.sourceforge.net
>> >>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>> >>
>> >>
>> >>
>> >>
>> >> ------------------------------------------------------------------------------
>> >> Subversion Kills Productivity. Get off Subversion & Make the Move to
>> >> Perforce.
>> >> With Perforce, you get hassle-free workflows. Merge that actually
>> >> works.
>> >> Faster operations. Version large binaries.  Built-in WAN optimization
>> >> and
>> >> the
>> >> freedom to use Git, Perforce or both. Make the move to Perforce.
>> >>
>> >> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
>> >> _______________________________________________
>> >> Csound-devel mailing list
>> >> Csound-devel@lists.sourceforge.net
>> >> https://lists.sourceforge.net/lists/listinfo/csound-devel
>> >>
>>
>>
>> ------------------------------------------------------------------------------
>> Subversion Kills Productivity. Get off Subversion & Make the Move to
>> Perforce.
>> With Perforce, you get hassle-free workflows. Merge that actually works.
>> Faster operations. Version large binaries.  Built-in WAN optimization and
>> the
>> freedom to use Git, Perforce or both. Make the move to Perforce.
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>
> ------------------------------------------------------------------------------
> Subversion Kills Productivity. Get off Subversion & Make the Move to
> Perforce.
> With Perforce, you get hassle-free workflows. Merge that actually works.
> Faster operations. Version large binaries.  Built-in WAN optimization and
> the
> freedom to use Git, Perforce or both. Make the move to Perforce.
> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

------------------------------------------------------------------------------
Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works. 
Faster operations. Version large binaries.  Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Yes, I use RELWITHDEBINFO for all windows releases, and usually but not always for debugging.

Best,
Mike

Update: I rebuilt with Debug and RelWithDebInfo just to double check
that the latter is still crashing (it is), and that the former is
still working (it is). I spent a bit of time in GDB but did not learn
anything new.

I'm going out of town tomorrow and will be back Wednesday. I'll resume
looking into this then.

On Thu, Mar 6, 2014 at 5:40 PM, Michael Gogins  wrote:
> Yes, I use RELWITHDEBINFO for all windows releases, and usually but not
> always for debugging.
>
> Best,
> Mike
>
> On Mar 6, 2014 5:24 PM, "Steven Yi"  wrote:
>>
>> Those flags (-O2 -g) correspond to -DCMAKE_BUILD_TYPE=RelWithDebInfo.
>> Unfortunately, I tried building with that and still got crashes.
>>
>> Question: are you using RelWithDebInfo when doing your releases?  If
>> so, I want to make sure I'm matching up my build for testing here with
>> what settings you have.
>>
>> Thanks!
>>
>> On Thu, Mar 6, 2014 at 12:27 PM, Michael Gogins
>>  wrote:
>> > Rather than maintain separate debug and release builds, I prefer to
>> > build
>> > only with -O2 -g. It is possible to debug with O2 and I rarely have
>> > found a
>> > significant speed advantage with O3.
>> >
>> > Best,
>> > Mike
>> >
>> >
>> > -----------------------------------------------------
>> > Michael Gogins
>> > Irreducible Productions
>> > http://michaelgogins.tumblr.com
>> > Michael dot Gogins at gmail dot com
>> >
>> >
>> > On Thu, Mar 6, 2014 at 11:41 AM, Steven Yi  wrote:
>> >>
>> >> Update: Using Release build type (which uses -O3), I get the crash.
>> >> At least that's a start for figuring this out.  I'll probably try an
>> >> -O2 build tomorrow to see if that work.
>> >>
>> >> On Thu, Mar 6, 2014 at 11:32 AM, Steven Yi  wrote:
>> >> > Hi Michael,
>> >> >
>> >> > Thanks for the email.  I had been doing most of what you had
>> >> > recommended already. The one thing that you mentioned that was very
>> >> > useful was the optimization thing. I forgot that the Custom.cmake had
>> >> > -O3 in it, which essentially make using CMAKE_BUILD_TYPE useless.
>> >> > (That flag being there has messed me up so many times now that I've
>> >> > removed it from the Custom.cmake.ex).
>> >> >
>> >> > Interestingly, with the debug build (without -O3), I did not get
>> >> > crashes (yay!). I did pull in some changes from develop branch
>> >> > between
>> >> > when I was testing and when I did this latest build, so I don't know
>> >> > yet if it is the change in optimization flag or if it was something
>> >> > fixed in develop. I'm rebuilding with -DCMAKE_RELEASE_TYPE=Release
>> >> > now
>> >> > and will retest with that.
>> >> >
>> >> > Thanks!
>> >> > steven
>> >> >
>> >> > On Thu, Mar 6, 2014 at 11:01 AM, Michael Gogins
>> >> >  wrote:
>> >> >> GDB can jump around, especially if you are debugging optimized code
>> >> >> (O2
>> >> >> or
>> >> >> O3).
>> >> >>
>> >> >> I suggest you set a breakpoint ahead of the crash, then step through
>> >> >> the
>> >> >> code. It's often faster to put in print statements on suspect
>> >> >> pointers,
>> >> >> data, etc. rather than manually inspecting them in gdb.
>> >> >>
>> >> >> Keep in mind when stepping, that with optimized code, GDB will
>> >> >> appear
>> >> >> to
>> >> >> enter a function or block of code more than once, jumping back to
>> >> >> "run
>> >> >> it
>> >> >> for real" after a bit.
>> >> >>
>> >> >> Also, is something happening in a different thread first, corrupting
>> >> >> data
>> >> >> that then causes this crash?
>> >> >>
>> >> >> Hope this helps,
>> >> >> Mike
>> >> >>
>> >> >> Hope this helps,
>> >> >> Mike
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >> -----------------------------------------------------
>> >> >> Michael Gogins
>> >> >> Irreducible Productions
>> >> >> http://michaelgogins.tumblr.com
>> >> >> Michael dot Gogins at gmail dot com
>> >> >>
>> >> >>
>> >> >> On Thu, Mar 6, 2014 at 10:45 AM, Steven Yi 
>> >> >> wrote:
>> >> >>>
>> >> >>> Hi All,
>> >> >>>
>> >> >>> I'm working on debugging some crashes with csound~ on Windows.  So
>> >> >>> far, I've found crashes with two of the examples that had come with
>> >> >>> Davis's installer:
>> >> >>>
>> >> >>> =============================
>> >> >>>
>> >> >>> -vocoder.maxpat
>> >> >>>
>> >> >>> I get a strange error in GDB:
>> >> >>>
>> >> >>> Program received signal SIGSEGV, Segmentation fault.
>> >> >>> [Switching to Thread 2944.0x290]
>> >> >>> vco2set (csound=0xe0c89f8, p=0xe2b05a8)
>> >> >>>     at c:/Users/Administrator/work/csound6/Opcodes/oscbnk.c:1950
>> >> >>> 1950        int     tnums[8] = { 0, 0, 1, 2, 1, 3, 4, 5 };
>> >> >>> (gdb) bt
>> >> >>> #0  vco2set (csound=0xe0c89f8, p=0xe2b05a8)
>> >> >>>     at c:/Users/Administrator/work/csound6/Opcodes/oscbnk.c:1950
>> >> >>> #1  0x6c51295a in insert (csound=csound@entry=0xe0c89f8,
>> >> >>> insno=insno@entry=1,
>> >> >>>     newevtp=newevtp@entry=0xe0cbbb0)
>> >> >>>     at c:/Users/Administrator/work/csound6/Engine/insert.c:273
>> >> >>> #2  0x6c517d39 in process_score_event
>> >> >>> (csound=csound@entry=0xe0c89f8,
>> >> >>>     evt=evt@entry=0xe0cbbb0, rtEvt=rtEvt@entry=0)
>> >> >>>     at c:/Users/Administrator/work/csound6/Engine/musmon.c:757
>> >> >>> #3  0x6c51a49b in sensevents (csound=csound@entry=0xe0c89f8)
>> >> >>>     at c:/Users/Administrator/work/csound6/Engine/musmon.c:946
>> >> >>>
>> >> >>> =============================
>> >> >>>
>> >> >>> -pluckSynth.max.pat
>> >> >>>
>> >> >>> (gdb) bt
>> >> >>> #0  0x6c6c1949 in create_instrument0
>> >> >>> (csound=csound@entry=0xa90b270,
>> >> >>>     root=root@entry=0xa9acab8,
>> >> >>> engineState=engineState@entry=0xa90b718,
>> >> >>>     varPool=0x9e2b758)
>> >> >>>     at
>> >> >>> c:/Users/Administrator/work/csound6/Engine/csound_orc_compile.c:505
>> >> >>> #1  0x6c6c320e in csoundCompileTree (csound=csound@entry=0xa90b270,
>> >> >>>     root=root@entry=0xa9efaf8)
>> >> >>>     at
>> >> >>>
>> >> >>> c:/Users/Administrator/work/csound6/Engine/csound_orc_compile.c:1394
>> >> >>> #2  0x6c6c372c in csoundCompileOrc (csound=csound@entry=0xa90b270,
>> >> >>>     str=str@entry=0x0)
>> >> >>>     at
>> >> >>>
>> >> >>> c:/Users/Administrator/work/csound6/Engine/csound_orc_compile.c:1679
>> >> >>> #3  0x6c61e81a in csoundCompileArgs (csound=csound@entry=0xa90b270,
>> >> >>> argc=5,
>> >> >>>     argc@entry=6, argv=argv@entry=0xa90b01c)
>> >> >>>     at c:/Users/Administrator/work/csound6/Top/main.c:234
>> >> >>> #4  0x6c61f6b0 in csoundCompile (csound=0xa90b270, argc=6,
>> >> >>> argv=0xa90b01c)
>> >> >>>     at c:/Users/Administrator/work/csound6/Top/main.c:490
>> >> >>> #5  0x6224a2c4 in dvx::CsoundObject::Compile (this=0xa905f58,
>> >> >>> lock=true)
>> >> >>>     at
>> >> >>>
>> >> >>> c:/Users/Administrator/work/csound6/frontends/max_csound_tilde/src/Cs
>> >> >>> Object.cpp:191
>> >> >>> #6  0x62249f91 in dvx::CsoundObject::Compile (this=0xa905f58)
>> >> >>>     at
>> >> >>>
>> >> >>> c:/Users/Administrator/work/csound6/frontends/max_csound_tilde/src/Cs
>> >> >>> Object.cpp:95
>> >> >>> #7  0x62247b37 in csound_startDeferred (x=0x3e732f0)
>> >> >>>     at
>> >> >>>
>> >> >>> c:/Users/Administrator/work/csound6/frontends/max_csound_tilde/src/cs
>> >> >>> ~.cpp:794
>> >> >>> #8  0x62247974 in csound_new (s=0x3a18eb8, argc=4, argv=0x11cdb36)
>> >> >>>     at
>> >> >>>
>> >> >>> c:/Users/Administrator/work/csound6/frontends/max_csound_tilde/src/cs
>> >> >>> ~.cpp:755
>> >> >>> #9  0x007921bb in getfn ()
>> >> >>> #10 0x011cdb36 in ?? ()
>> >> >>> #11 0x00788a8c in object_dictionary_fromnewargs ()
>> >> >>> #12 0x011cd760 in ?? ()
>> >> >>> #13 0x000305fc in ?? ()
>> >> >>> Cannot access memory at address 0xbfec0007
>> >> >>>
>> >> >>> again this is a weird one as it's crashing on a line that's setting
>> >> >>> some local variables to the function.
>> >> >>>
>> >> >>> =============================
>> >> >>>
>> >> >>> I've compiled Csound with mingw (32-bit), with
>> >> >>> -DCMAKE_BUILD_TYPE=Debug.  To debug, I'm using"
>> >> >>>
>> >> >>> gdb /c/Program\ Files\ \(x86\)/Cycling\ \'74/Max\ Runtime\
>> >> >>> 6.1/MaxRT.exe
>> >> >>>
>> >> >>> I can run the csd's for those patches from the commandline using
>> >> >>> csound without a crash. Also, there is no other installation of
>> >> >>> Csound
>> >> >>> besides the one I compiled.
>> >> >>>
>> >> >>> It's an odd error for both of the above, so I'm a little stumped at
>> >> >>> the moment. I suspect the bug is elsewhere and that gdb is just
>> >> >>> getting confused.  If anyone has some suggestions or has time to
>> >> >>> work
>> >> >>> along here that'd be great.
>> >> >>>
>> >> >>> Thanks!
>> >> >>> steven
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>> ------------------------------------------------------------------------------
>> >> >>> Subversion Kills Productivity. Get off Subversion & Make the Move
>> >> >>> to
>> >> >>> Perforce.
>> >> >>> With Perforce, you get hassle-free workflows. Merge that actually
>> >> >>> works.
>> >> >>> Faster operations. Version large binaries.  Built-in WAN
>> >> >>> optimization
>> >> >>> and
>> >> >>> the
>> >> >>> freedom to use Git, Perforce or both. Make the move to Perforce.
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
>> >> >>> _______________________________________________
>> >> >>> Csound-devel mailing list
>> >> >>> Csound-devel@lists.sourceforge.net
>> >> >>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >> ------------------------------------------------------------------------------
>> >> >> Subversion Kills Productivity. Get off Subversion & Make the Move to
>> >> >> Perforce.
>> >> >> With Perforce, you get hassle-free workflows. Merge that actually
>> >> >> works.
>> >> >> Faster operations. Version large binaries.  Built-in WAN
>> >> >> optimization
>> >> >> and
>> >> >> the
>> >> >> freedom to use Git, Perforce or both. Make the move to Perforce.
>> >> >>
>> >> >>
>> >> >> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
>> >> >> _______________________________________________
>> >> >> Csound-devel mailing list
>> >> >> Csound-devel@lists.sourceforge.net
>> >> >> https://lists.sourceforge.net/lists/listinfo/csound-devel
>> >> >>
>> >>
>> >>
>> >>
>> >> ------------------------------------------------------------------------------
>> >> Subversion Kills Productivity. Get off Subversion & Make the Move to
>> >> Perforce.
>> >> With Perforce, you get hassle-free workflows. Merge that actually
>> >> works.
>> >> Faster operations. Version large binaries.  Built-in WAN optimization
>> >> and
>> >> the
>> >> freedom to use Git, Perforce or both. Make the move to Perforce.
>> >>
>> >>
>> >> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
>> >> _______________________________________________
>> >> Csound-devel mailing list
>> >> Csound-devel@lists.sourceforge.net
>> >> https://lists.sourceforge.net/lists/listinfo/csound-devel
>> >
>> >
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > Subversion Kills Productivity. Get off Subversion & Make the Move to
>> > Perforce.
>> > With Perforce, you get hassle-free workflows. Merge that actually works.
>> > Faster operations. Version large binaries.  Built-in WAN optimization
>> > and
>> > the
>> > freedom to use Git, Perforce or both. Make the move to Perforce.
>> >
>> > http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
>> > _______________________________________________
>> > Csound-devel mailing list
>> > Csound-devel@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/csound-devel
>> >
>>
>>
>> ------------------------------------------------------------------------------
>> Subversion Kills Productivity. Get off Subversion & Make the Move to
>> Perforce.
>> With Perforce, you get hassle-free workflows. Merge that actually works.
>> Faster operations. Version large binaries.  Built-in WAN optimization and
>> the
>> freedom to use Git, Perforce or both. Make the move to Perforce.
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
> ------------------------------------------------------------------------------
> Subversion Kills Productivity. Get off Subversion & Make the Move to
> Perforce.
> With Perforce, you get hassle-free workflows. Merge that actually works.
> Faster operations. Version large binaries.  Built-in WAN optimization and
> the
> freedom to use Git, Perforce or both. Make the move to Perforce.
> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

------------------------------------------------------------------------------
Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works. 
Faster operations. Version large binaries.  Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net