[Cs-dev] Memory issues in cs6 rc3?
| Date | 2013-06-17 20:53 |
| From | Richard Henninger |
| Subject | [Cs-dev] Memory issues in cs6 rc3? |
| Attachments | None None |
|
After downloading the latest rc3 for windows, I now get more crashes upon calling csoundDestroy - illegal access of memory - than I did with the 1st rc3 copy.
I thought Victor and I had isolated it to my use of Tasks for when I stopped using those, the crashes upon closing disappeared. He also added a fix to csoundReset to make it idempotent and independent of whether csoundStart had been called which may or
may not have made it to the latest copy.
In the latest copy, I get the crashes even when no Tasks are used.
In reverting back to rc2 of May 5, all crashes evaporated. Along the way, I noticed that I had to change invalue/outvalue callbacks for strings to act like char* rather than char** as used by rc3.
Which is right? I had thought that void* would dereference to MYFLT* or char* as it did in rc2, but I can live with either: char* or char** if that is semantically what the spec means.
Did rc3 fix void* to mean a pointer to a char* or was a new issue introduced here and it should have still been char* only. I am beginning to suspect that some memory inconsistencies may have crept in during the month of May that might benefit from some
more rigorous testing at the ”c”level for memory leaks.
Richard Henninger
richard@rghmusic.com |
| Date | 2013-06-17 21:26 |
| From | Victor Lazzarini |
| Subject | Re: [Cs-dev] Memory issues in cs6 rc3? |
| Attachments | None None |
I am not sure which is the source for the binaries that you are using for RC3. But if you can isolate the crashes in a C program, I can take a look. Regarding invalue/outvalue and strings, I will look closely because these may be out of step with the changes in string variable code. Victor On 17 Jun 2013, at 20:53, Richard Henninger wrote:
Dr Victor Lazzarini Senior Lecturer Dept. of Music NUI Maynooth Ireland tel.: +353 1 708 3545 Victor dot Lazzarini AT nuim dot ie |
| Date | 2013-06-17 22:05 |
| From | Richard Henninger |
| Subject | Re: [Cs-dev] Memory issues in cs6 rc3? |
| Attachments | None None |
|
Thanks Victor.
Re strings, what is the expected dereferencing semantic of outval callback’s void* for a string channel? char* or char**? since rc3 and rc2 differ respectively. What will “fixed” look like?
Re crash": one simple scenario that started failing with the later copy of rc3 was compiling xanadu.csd (csoundCompile which includes csoundStart) , performing one ksmps cycle (csoundPerformKsmps) followed by examining f1 1st via csoundGetTable and again
by csoundTableCopyOut and confirming that they are the same. That part works fine, but rc3 crashes upon csoundDestroy with an illegal memory access violation while rc2 and the earlier rc3 do/did not. (BTW, doc doesn’t say, but should I leave room for the
guard point in csoundTableCopyOut?)
I’ve reverted back to rc2 in my system and all is well. However, if this rc3 problem stays a mystery and we need more data, maybe I’ll have to set myself up to compile my own rc3 build to match source and object and debug from here to know which free()
is bogus or at least make an isolated c environment making a def file for the dll: one level deeper than I was planning on.
Still, if you don’t spot anything... We need to get 6 ready for prime time, so making such an environment would be a good investment.
Richard Henninger
richard@rghmusic.com From: Victor
Lazzarini
Sent: Monday, June 17, 2013 4:27 PM To: Developer discussions I am not sure which is the source for the binaries that you are using for RC3. But if you can isolate the crashes in a C program, I can take a look.
Regarding invalue/outvalue and strings, I will look closely because these may be out of step with the changes in string variable code.
Victor
On 17 Jun 2013, at 20:53, Richard Henninger wrote:
Dr Victor Lazzarini
Senior Lecturer
Dept. of Music
NUI Maynooth Ireland
tel.: +353 1 708 3545
Victor dot Lazzarini AT nuim dot ie
|
| Date | 2013-06-17 23:26 |
| From | Richard Henninger |
| Subject | Re: [Cs-dev] Memory issues in cs6 rc3? |
| Attachments | None None |
|
BTW, binaries were taken from rc3 setup installers available last Saturday morning and this morning respectively from the sourceforge site.
Richard Henninger
richard@rghmusic.com From: Richard
Henninger
Sent: Monday, June 17, 2013 5:06 PM To: Developer discussions Thanks Victor.
Re strings, what is the expected dereferencing semantic of outval callback’s void* for a string channel? char* or char**? since rc3 and rc2 differ respectively. What will “fixed” look like?
Re crash": one simple scenario that started failing with the later copy of rc3 was compiling xanadu.csd (csoundCompile which includes csoundStart) , performing one ksmps cycle (csoundPerformKsmps) followed by examining f1 1st via csoundGetTable and again
by csoundTableCopyOut and confirming that they are the same. That part works fine, but rc3 crashes upon csoundDestroy with an illegal memory access violation while rc2 and the earlier rc3 do/did not. (BTW, doc doesn’t say, but should I leave room for the
guard point in csoundTableCopyOut?)
I’ve reverted back to rc2 in my system and all is well. However, if this rc3 problem stays a mystery and we need more data, maybe I’ll have to set myself up to compile my own rc3 build to match source and object and debug from here to know which free()
is bogus or at least make an isolated c environment making a def file for the dll: one level deeper than I was planning on.
Still, if you don’t spot anything... We need to get 6 ready for prime time, so making such an environment would be a good investment.
Richard Henninger
richard@rghmusic.com From: Victor
Lazzarini
Sent: Monday, June 17, 2013 4:27 PM To: Developer discussions I am not sure which is the source for the binaries that you are using for RC3. But if you can isolate the crashes in a C program, I can take a look.
Regarding invalue/outvalue and strings, I will look closely because these may be out of step with the changes in string variable code.
Victor
On 17 Jun 2013, at 20:53, Richard Henninger wrote:
Dr Victor Lazzarini
Senior Lecturer
Dept. of Music
NUI Maynooth Ireland
tel.: +353 1 708 3545
Victor dot Lazzarini AT nuim dot ie
|
| Date | 2013-06-18 08:03 |
| From | Victor Lazzarini |
| Subject | Re: [Cs-dev] Memory issues in cs6 rc3? |
| Attachments | None None |
Strings used to be held in plain char * pointers inside Csound, and MYFLT * were just cast as char *. This did not allow much flexibility. So strings now are STRINGDAT{ char *data; int size; } . The invalue opcode had not been completely converted to work with there and that could explain the need for char** rather than char *. On 17 Jun 2013, at 22:05, Richard Henninger wrote:
Dr Victor Lazzarini Senior Lecturer Dept. of Music NUI Maynooth Ireland tel.: +353 1 708 3545 Victor dot Lazzarini AT nuim dot ie |
| Date | 2013-06-18 15:06 |
| From | Richard Henninger |
| Subject | Re: [Cs-dev] Memory issues in cs6 rc3? |
| Attachments | None None |
|
That makes sense.
So do you think in/outvalue’s callbacks’ void* for string channels should dereference directly to a STRINGDAT* structure (like PVS channels point to a structure) to get both length and char*? Or should void* point where STRINGDAT.data points and use csoundGetChannelDataSize
in lieu of obsolete csoundGetStrVarMaxLen for char[] length (kind of more backwards compatible, I suppose)?
Richard Henninger
richard@rghmusic.com From: Victor
Lazzarini
Sent: Tuesday, June 18, 2013 3:05 AM To: Developer discussions Strings used to be held in plain char * pointers inside Csound, and MYFLT * were just cast as char *. This did not allow much flexibility.
So strings now are STRINGDAT{ char *data; int size; } . The invalue opcode had not been completely converted to work with there and
that could explain the need for char** rather than char *.
On 17 Jun 2013, at 22:05, Richard Henninger wrote:
Dr Victor Lazzarini
Senior Lecturer
Dept. of Music
NUI Maynooth Ireland
tel.: +353 1 708 3545
Victor dot Lazzarini AT nuim dot ie
|
| Date | 2013-06-18 16:00 |
| From | Victor Lazzarini |
| Subject | Re: [Cs-dev] Memory issues in cs6 rc3? |
| Attachments | None None |
No, you just use it as before: the callbacks will dereference the variables to char * pointers. I have changed the code to allow for this, and the strings are allocated to a fixed size of 256 bytes (in total). In the case of outvalue, you should check the size of the string that has been passed to the callback, if you need to. That is dynamically variable, because it originates from a string variable in Csound. csoundGetStrVarMaxLen() has been removed from the API. csoundGetChannelDataSize() will not be relevant here as the Csound channel is not used to store any data in this case (the data is passed directly to/from Csound variables). Victor On 18 Jun 2013, at 15:06, Richard Henninger wrote:
Dr Victor Lazzarini Senior Lecturer Dept. of Music NUI Maynooth Ireland tel.: +353 1 708 3545 Victor dot Lazzarini AT nuim dot ie |
| Date | 2013-06-18 17:49 |
| From | Richard Henninger |
| Subject | Re: [Cs-dev] Memory issues in cs6 rc3? |
| Attachments | None None |
|
Thanks, Victor. That makes it all clear and seems quite logical.
Richard Henninger
richard@rghmusic.com From: Victor
Lazzarini
Sent: Tuesday, June 18, 2013 11:00 AM To: Developer discussions No, you just use it as before: the callbacks will dereference the variables to char * pointers. I have changed the code to allow for this, and
the strings are allocated to a fixed size of 256 bytes (in total).
In the case of outvalue, you should check the size of the string that has been passed to the callback, if you need to. That is
dynamically variable, because it originates from a string variable in Csound.
csoundGetStrVarMaxLen() has been removed from the API. csoundGetChannelDataSize() will not be relevant here as the Csound
channel is not used to store any data in this case (the data is passed directly to/from Csound variables).
Victor
On 18 Jun 2013, at 15:06, Richard Henninger wrote:
Dr Victor Lazzarini
Senior Lecturer
Dept. of Music
NUI Maynooth Ireland
tel.: +353 1 708 3545
Victor dot Lazzarini AT nuim dot ie
|
| Date | 2013-06-19 01:10 |
| From | Andres Cabrera |
| Subject | Re: [Cs-dev] Memory issues in cs6 rc3? |
| Attachments | None None |
Hi Victor, You are right that this makes the opcodes almost unusable for strings... Maybe it would be better to change them somehow to handle this better?Cheers, Andrés On Tue, Jun 18, 2013 at 5:00 AM, Victor Lazzarini <Victor.Lazzarini@nuim.ie> wrote:
|
| Date | 2013-06-19 01:58 |
| From | Michael Gogins |
| Subject | Re: [Cs-dev] Memory issues in cs6 rc3? |
| Attachments | None None |
I guess I sort of thought this would already be possible. .. Anyway it is a good idea. On Jun 18, 2013 8:11 PM, "Andres Cabrera" <mantaraya36@gmail.com> wrote:
|
| Date | 2013-06-19 03:53 |
| From | Andres Cabrera |
| Subject | Re: [Cs-dev] Memory issues in cs6 rc3? |
| Attachments | None None |
I think it is possible for chnget/chnset, but currently not for invalue/outvalue that are callback based and pass a pointer to the data rather than the variable. Cheers,Andrés On Tue, Jun 18, 2013 at 5:58 PM, Michael Gogins <michael.gogins@gmail.com> wrote:
|
| Date | 2013-06-19 07:05 |
| From | Victor Lazzarini |
| Subject | Re: [Cs-dev] Memory issues in cs6 rc3? |
| Attachments | None None |
| I'd be happy for the callbacks to be changed to make the strings support better, but note that the fixed size is not completely unusable, since that was exactly how it was in Csound 5. As for the other changes, it's an idea, but maybe we should leave them as is now for 6.00 (since we want to release). The locks used are spinlocks and they are not too bad. Victor On 19 Jun 2013, at 01:10, Andres Cabrera wrote:
Dr Victor Lazzarini Senior Lecturer Dept. of Music NUI Maynooth Ireland tel.: +353 1 708 3545 Victor dot Lazzarini AT nuim dot ie |
| Date | 2013-06-22 02:07 |
| From | Andres Cabrera |
| Subject | Re: [Cs-dev] Memory issues in cs6 rc3? |
| Attachments | None None |
You're right, but we need to make sure the APi can accomodate them before release. Cheers,Andrés On Tue, Jun 18, 2013 at 11:05 PM, Victor Lazzarini <Victor.Lazzarini@nuim.ie> wrote:
|