DLL Horror!
Callistus Chui
As STL getting more and more popular, it is almost sure developer would end
up using one of those STL objects inside a DLL. According to Microsoft,
classes exported from a DLL always reside within the context of the DLL.
Unfortunate, with this mentioned, it becomes very confusing as to the
principle of DLL. As far as I know, any data allocated by the DLL's code
gets mapped into the EXE's memory address space. It is simple for me to
imagine that there is only one copy of an allocated data that can be
accessed by both the EXE and the DLL. However, this is not true. I have
experienced it, and it is HORRABLE. No matter how I try to assign a value
to a member variable, its value will automatically disappear in one place
and re-appear again in another place. So, there are two allocated memory
for the same member variable. Here are some question after playing with
DLLs implementation.
Two key facts:
By default, none STL objects exported from a DLL get allocated inside the
context of the DLL.
By default, STL objects exported from a DLL get allocated inside the context
of the EXE.
1. What is DLL context? Does that mean that DLL has its own memory space
that cannot be accessed by the EXE without some resolution?
2. MSDN article ID: Q168958 explains a resolution to keep exported STL
objects allocated inside the context of the DLL, instead of the context of
the EXE. I personaly dislike this techique because I always want everything
allocated inside the context of the EXE. There should only one memory space
for the EXE, no matter how many DLL it uses. Does this reasoning make any
sense to you?
3. MSDN article ID: Q122675 suggests three resolution to keep a normal
object (none STL object) allocated inside the context of the EXE, instead of
the context of the DLL. These are the resolutions I like. However, I am
not sure if everything inside the object was also allocated inside the
context of the EXE, even if it was a STL object. Do you know?
If I am right on number 3, than I can safely use the technique and garantee
to avoid ghost variable that its value keep appearing and disappearing with
no cause at all.
Silvio Bierman
problems to consider here, though.
First of all, a DLL and an EXE can both have a seperate heap. That means
that when memory is allocated (using new) by an STL object in the DLL heap
(when the STL code is residing in the DLL) and is freed (delete) in the EXE
heap (by STL code residing in the EXE) the EXE heap will assert and a
runtime error is born. Obviously the reverse scenario also bangs.
This problem can be prevented by using the 'DLL version' of the runtime
library in both the EXE and the DLL. That way both DLL code and EXE code
share the same heap.
The second problem is harder to circumvent. The STL code generates static
members of STL classes which are crucial to proper STL behaviour. The STL
code (naturally) assumes that there is only one instance of such static
members. When STL code is compiled both in the DLL and in the EXE, two
instances of the code, but also two instances of the static members are
generated.
The STL objects contain references to these static members and the STL code
operating on them depends on the same static members. Passing STL objects
created by the DLL (containing references to the DLL static members) to STL
code generated in the EXE (expecting STL object referencing the EXE static
members) will cause major explosions.
Simply said, the STL supplied with VC6 is not DLL safe. Applying the patches
from Dinkumware http://www.dinkumware.com/vc_fixes.html solves a lot of
these problems though.
General advice: when creating objects defined in some DLL and containign STL
members, make sure they have non-inline (copy) constructors and destructors.
Directly accessing the STL members stays risky though.
Lets hope Microsoft will fix this problem (or limitation by design, as they
call it) in VC7
Silvio Bierman
Callistus Chui <call...@home.com> wrote in message
news:#4Z7OyTv#GA.285@cppssbbsa04...
Bob Rundle
sayings around.
I have been using stl members in exported DLL classes for a long time
without a problem. However recently I tried to pass a set<int> to a DLL
procedure...Boom.
I have since realized that the reason that my stl members in my exported
classes never cause a problem is that only the DLL code touches them. Only
in this limited sense are stl classes "DLL safe".
Regards,
Bob Rundle
Silvio Bierman <sbie...@idfix.nl> wrote in message
news:7kqcm7$l5g$1...@news1.xs4all.nl...
Ron Ruble
Bob Rundle wrote in message ...
>I love the "Limitation by design" part. It is one of the better Microspeak
>sayings around.
I don't know if you can really call this a 'limitation by design', though.
MS didn't design their STL implementation; they purchased
Dinkumware's. it might be better termed a "Limitation by
failure to design" ;>
>> The second problem is harder to circumvent. The STL code generates static
>> members of STL classes which are crucial to proper STL behaviour. The STL
>> code (naturally) assumes that there is only one instance of such static
>> members. When STL code is compiled both in the DLL and in the EXE, two
>> instances of the code, but also two instances of the static members are
>> generated.
And fixing that would take a coordinated effort in both how
the static members are instantiated and how the DLL and
exe members are initialized. Off the top of my head, I think
it would take some fancy footwork to force overcome this one
safely, without adding even more inconsistencies to the
way templates work in VC++.
P.J. Plauger
>I don't know if you can really call this a 'limitation by design', though.
>MS didn't design their STL implementation; they purchased
>Dinkumware's. it might be better termed a "Limitation by
>failure to design" ;>
Cheap shot. In point of fact, Microsoft asked for and got a library designed
to be statically linked. They never mentioned DLLs to us, or told us about
any of the limitations of shared heaps and statics across DLLs. Once we
became aware of the problems, we began responding to them pretty
quickly.
>>> The second problem is harder to circumvent. The STL code generates static
>>> members of STL classes which are crucial to proper STL behaviour. The STL
>>> code (naturally) assumes that there is only one instance of such static
>>> members. When STL code is compiled both in the DLL and in the EXE, two
>>> instances of the code, but also two instances of the static members are
>>> generated.
>
>And fixing that would take a coordinated effort in both how
>the static members are instantiated and how the DLL and
>exe members are initialized. Off the top of my head, I think
>it would take some fancy footwork to force overcome this one
>safely, without adding even more inconsistencies to the
>way templates work in VC++.
Well, we eliminated the static members over a year ago, and have been
giving away the fixed code ever since. See
http://www.dinkumware.com/vc_fixes.html
Since then, we have worked with Microsoft and on our own to improve
the usability of STL with DLLs. The multiple heap problem remains, but
that is beyond our control.
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
Ron Ruble
P.J. Plauger wrote in message <7l14rd$7he$1...@news.harvard.net>...
>Ron Ruble wrote in message <7l11ch$t1p$1...@bgtnsc03.worldnet.att.net>...
>Cheap shot. In point of fact, Microsoft asked for and got a library
designed
>to be statically linked. They never mentioned DLLs to us, or told us about
>any of the limitations of shared heaps and statics across DLLs. Once we
>became aware of the problems, we began responding to them pretty
>quickly.
I apologize. I was not implying that Dinkumware failed to design,
but rather that Microsoft has been playing catch-up to the C and
C++ standards for a long time, and it seems they still have a
failure to plan and design adequately.
Dinkumware has done a fine job with the STL. MS, on the
other hand, has been adding features to DLLs in a very
ill-considered fashion.
The main point I was trying to make is that with the number of
questions that get asked about problems allocating memory in
an app, and freeing it in a DLL, trying to coordinate STL objects
for use in a similar manner might introduce more troubles
than it's worth.
Again, I apologize for my earlier comment.
>Since then, we have worked with Microsoft and on our own to improve
>the usability of STL with DLLs. The multiple heap problem remains, but
>that is beyond our control.
Agreed. And that's why I think it would be best to ignore the idea
of coordinating STL object use across different heaps, until the
compiler is much more compliant in it's template handling.
Bob Rundle
the stl. I have many dog-eared books of yours on my shelf. Including one
on the stl. I was at a C++ conference many years ago and some character
named Voight was complaining about it. I'm not sure why he was
upset...thought he owned the stl I suppose.
Anyway, might I gently say that I don't think ignorance of DLLs is a
suitable defence. There is not much code on PC's that doesn't find its way
into DLLs. In this way the PC is much more advanced than Unix. I was
trying to put some code in a shared library on an HPUX box recently.
Compiler complained about code that wasn't position independent. I haven't
thought about position independence in a long, long time.
Best regards,
Bob Rundle
P.J. Plauger <p...@plauger.com> wrote in message
news:7l14rd$7he$1...@news.harvard.net...
> Ron Ruble wrote in message <7l11ch$t1p$1...@bgtnsc03.worldnet.att.net>...
> >I don't know if you can really call this a 'limitation by design',
though.
> >MS didn't design their STL implementation; they purchased
> >Dinkumware's. it might be better termed a "Limitation by
> >failure to design" ;>
>
> Cheap shot. In point of fact, Microsoft asked for and got a library
designed
> to be statically linked. They never mentioned DLLs to us, or told us about
> any of the limitations of shared heaps and statics across DLLs. Once we
> became aware of the problems, we began responding to them pretty
> quickly.
>
>
> >>> The second problem is harder to circumvent. The STL code generates
static
> >>> members of STL classes which are crucial to proper STL behaviour. The
STL
> >>> code (naturally) assumes that there is only one instance of such
static
> >>> members. When STL code is compiled both in the DLL and in the EXE, two
> >>> instances of the code, but also two instances of the static members
are
> >>> generated.
> >
> >And fixing that would take a coordinated effort in both how
> >the static members are instantiated and how the DLL and
> >exe members are initialized. Off the top of my head, I think
> >it would take some fancy footwork to force overcome this one
> >safely, without adding even more inconsistencies to the
> >way templates work in VC++.
>
> Well, we eliminated the static members over a year ago, and have been
> giving away the fixed code ever since. See
>
> http://www.dinkumware.com/vc_fixes.html
>
> Since then, we have worked with Microsoft and on our own to improve
> the usability of STL with DLLs. The multiple heap problem remains, but
> that is beyond our control.
>
Andrew Osman
said M$ asked for a statically linkable STL.
-Andy
Bob Rundle <rr98...@shellus.com> wrote in message
news:Vr3d3.10$I7.16@snews2...
John Guiver
exe. I tried exporting an instantiation of std::set<int> as detailed in MSDN
Q168958, in spite of the claim that sets cannot be exported. Interestingly,
the debug version of my program then fortuitously worked, but the release
version still failed in the same way.
Is P.J. Plauger saying that the Dinkumware fixes will solve this problem? If
so, which fix(es).
Thanks
John G.
Bob Rundle wrote in message ...
>I have been using stl members in exported DLL classes for a long time
>without a problem. However recently I tried to pass a set<int> to a DLL
>procedure...Boom.
>
>I have since realized that the reason that my stl members in my exported
>classes never cause a problem is that only the DLL code touches them. Only
>in this limited sense are stl classes "DLL safe".
Silvio Bierman wrote in message <7kqcm7$l5g$1...@news1.xs4all.nl>...
>The STL objects contain references to these static members and the STL code
>operating on them depends on the same static members. Passing STL objects
>created by the DLL (containing references to the DLL static members) to STL
>code generated in the EXE (expecting STL object referencing the EXE static
>members) will cause major explosions.
P.J. Plauger wrote in message <7l14rd$7he$1...@news.harvard.net>...
Bob Rundle
http://www.dinkumware.com/vc_fixes.html
I haven't tried them, so I don't know what they do. It really doesn't seem
right updating a piece of a product from a subvendor. Is MS going to
support these changes in future updates? Why hasn't MS put these fixes out
in a SP? The whole business seems very unclean. If I run into serious
problems I will apply the fixes, but not until then. This is not my usual
practice but there is a lot going on beneath the surface here.
John Guiver <John_...@aspentec.com> wrote in message
news:eNWt3Yzw#GA.266@cppssbbsa03...
P.J. Plauger
>
>http://www.dinkumware.com/vc_fixes.html
>
>I haven't tried them, so I don't know what they do. It really doesn't seem
>right updating a piece of a product from a subvendor. Is MS going to
>support these changes in future updates? Why hasn't MS put these fixes out
>in a SP? The whole business seems very unclean. If I run into serious
>problems I will apply the fixes, but not until then. This is not my usual
>practice but there is a lot going on beneath the surface here.
Less than meets the eye, actually. Microsoft has suffered unfortunate
delays in upgrading the VC++ library. We began offering free fixes last
year for the worst bugs. More recently, we produced a more coherent
upgrade as a product. We view it as an interim measure until a new
release of VC++ comes out.