[fpc-devel] Access Violation with nested DLL's compiled by FPC(and some more info on bug #4538)
Stefan van den Berg
chtk at xs4all.nl
Sat Dec 10 14:08:02 CET 2005
>>>> 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.
>> 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
>> 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.
> 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
More information about the fpc-devel