jamoma/JamomaSupport — comment on commit 6ba50d694a565446f1c3fb9b180aefbc0bbf8b73
File:  line 0
By adrian-gierakowski:

Hi Tim,

First I need to correct myself: I wrote that this only crashed on windows
64bit only, but I was wrong. I had actually fixed this bug on my 32bit
machine a couple of months ago and I committed the changes but haven't
pushed. Since the fix wasn't in the repository, I was compiling different
code on the two machines and the 64bit was crashing, and the 32bit worked
since it had the fixes.

Now to your questions:

getString() doesn't fail and the returned size is right. I also checked
that char is used (not wchar).

After reading the folowing thread:
http://www.gamedev.net/topic/337108-passing-stdstring-over-dll-boundaries/page__st__20

and stepping through the code in the debugger, I think it happens like this:

1.getString() is defined in Foundation and it returns a string (which
is actually a copy of the original string residing in the TTSymbol: name),
which is allocated on the heap belonging to the CRT within Foundation (all
the libs and externals compiled with MT, meaning that they have their
own, separate heaps).

2.When .length() returns, the string returned by getString() is no longer
needed and is being deallocated, but since .length() was called
form jcom.spatDisplay it cannot be deallocated correctly because the string
belongs to the heap of Foundation.

I am not 100% though, it's more of an educated guess :)

best

Adrian

On Wed, Nov 9, 2011 at 7:11 PM, Timothy Place <
reply@reply.github.com>wrote:

> I'm glad this fixed the crashing with SpatDisplay on Win64 - thanks for
> figuring this out!
>
> What I don't understand is why this fixes it. Does get getString() fail?
> Does it return a size that is wrong? Maybe using wchar instead of char
> internally?
>
> ---
> Reply to this email directly or view it on GitHub:
>
> https://github.com/jamoma/JamomaSupport/commit/6ba50d694a565446f1c3fb9b180aefbc0bbf8b73#commitcomment-706122
>

--
Adrian Gierakowski