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

[Stefan van den Berg]

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.

> Did you include the sharemem unit in the delphi program maybe, which 
> caused it to work there just fine but not in FPC?  If not, how long 
> was the program tested and how many users actually used the program 
> without problems? Sometimes you can get away with strings 
> temporarily, but the bugs pop up later or in random occurrences.
> 
I don't think the sharemem unit is used anywhere in the origial code. I
could be wrong, though. I don't have the code here at home. I'll have a
look on Monday.

The application is still under development, so it's not actually been
used/tested on a large scale. For as far as i know, the application,
compiled with Delphi, doesn't show any of the problems I get when the
app is compiled with FPC. But that could just as well be dumb luck.

> The general safe rule is to never return a string into a function 
> result when passing it to a DLL without shared memory.

I'm not sure what you ment by that. Did you mean it's unsafe to return 
an ansistring from a function exported by a dll per say? Or did you mean 
passing an ansistring to a function imported from a dll, manipulating 
that string and returning it?

> There are ways to use ansistrings without shared memory, such as
> using setlength calls in certain places, and taking extra caution
> (like using CONST parameters in some cases).. but I've learned that
> it takes extra brain effort to try and trick/escape the reference
> counter, so using pchars makes you extra safe. That is, assuming you
> study pchars thoroughly (and there are a lot of incorrect information
> out there so a book needs to be written on pchars).
> 
> The other problem with trying to escape/trick the reference counter 
> is you take extra CPU power to do it. The real disadvantage is not 
> the extra cpu that it could cost, but the maintainability. Eventually
>  your tricks catch up with you and you make a small mistake when 
> trying to trick the reference counter. Whereas if you go in knowing 
> what memory you are allocating, you can understand your mistakes and 
> fix them rather than try to play more tricks.
> 
> 
> -- L505
> 
> _______________________________________________ fpc-devel maillist  -
>  fpc-devel at lists.freepascal.org 
> http://lists.freepascal.org/mailman/listinfo/fpc-devel
> 
>