[fpc-devel] Access Violation with nested DLL's compiledbyFPC(andsome more info on bug #4538)

[L505]

> I still have not seen a single actual problem mentioned with an
> explanation by what exactly it is caused, only vague hand waving
> warning for strange and inexplicable problems. I'm really interested
> by what these problems are and can be caused. Does every dll have its
> own memory manager data structures and is indeed the problem that
> memory allocated by one is free "to" another (as I described in my
> previous mail)?
>
> That would seem very strange to me though, since this could be easily
> solved by making the RTL/system unit a dynamically linked library and
> linking all other libraries to that (so there is only one system unit
> with only one memory manager).
>
> Or is it something else?
>
>
> Jonas


What I originally thought one of the problems was, when trying to receive a function
result, was that the DLL thinks that there is no need to keep the string in the
memory. Why should it, if no other code in the DLL uses the string?  Unless the DLL
has some knowledge about the Exe using the string. Does it? Does it know about the
reference count that the exe created? When the exe tries to use the function result,
it goes in to the DLL space and tries to grab the function result in memory, but it
isn't there because the DLL threw it away (unless hte DLL does know about the
reference count the exe created.. does it?). On certain occassions, the DLL hasn't
thrown it away and the program runs fine. That was my assumption, but not
neccessarily the correct one.

Can we confirm for sure that above is the wrong assumption?

Where is the "reference count" actually stored anyway, and who as access to the
reference count - just the dll/exe who created the string, or is it accessible by
both of them? I do need to learn more about reference count science.