[fpc-devel] Access Violation with nested DLL's compiled by FPC(and some more info on bug #4538)

Marc Weustink marc at dommelstein.net
Sun Dec 11 16:31:10 CET 2005


Stefan van den Berg wrote:
> L505 wrote:
> 
>>>>> Before we can say something, what functions do you call, what 
>>>>> params, what calling convention etc. Does it happen in one specific 
>>>>> sequence of calls, to specific functions/methods etc.
>>>>>
>>>>> Please provide some more info.
>>>>
>>>>
>>>>
>>>> http://www.freepascal.org/bugs/showsource.php3?ID=4538
>>>
>>>
>>> Whoops, I didn't saw that there was a bugrep.
>>>
>>> I'm not shure if FPC behaves the same as Delphi, but I think it does.
>>>
>>> In Delphi you cannot exchange ansistrings between dlls, unless you 
>>> have a shared memory manager. Normally each exe (or dll) has its own 
>>> memory manager. So when you pass a string to a dll and it it goes out 
>>> of scope there (since it is changed) it is released there.
>>>  So a allocated memory block from one manager is freed in another. 
>>> This gives all kinds of unexpected errors at strange places.
>>>
>>> IIRC the way constant strings are allocates it changed, so that may
>>>  be the reason that you didn't see the error on dlls generated by
>>> an older fpc.
>>>
>>> Marc
>>>
>>
>>
>> To the original person who posed the bug report: As Marc stated.. it 
>> is definitely a bad idea to use an ansistring as a function result in
>>  DLL's - unless it was a BPL or you were using shared memory.
>>
> The usage of strings in the samples was just to verify which code was
> executed and where things went wrong. I wasen't aware of the fact that
> that alone could cause problems. In the actual application mainly
> objects are passed to functions as regular and out parameters and a
> boolean is returned to indicate success or failure.

Also passing objects may couse problems. Operators like "is" will fail, 
since TObject defined in dll1 is not equal to TObject defined in dll2.
They have  the same memory layout (if compiled by the same compiler), 
but the class pointer is different, so they are different classes.

I don't think this is the couse of your exception, but sertenly 
something to keep in mind.

Marc




More information about the fpc-devel mailing list