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 -
[email protected]
http://lists.freepascal.org/mailman/listinfo/fpc-devel
_______________________________________________
fpc-devel maillist - [email protected]
http://lists.freepascal.org/mailman/listinfo/fpc-devel
