BorlandTalk.com

Fraser Ross · Guest

I have a function in a DLL module that I've reduced to simply creating a
std::ofstream object with the default constructor. When the calling
module shuts down there is an access violation. I can't get rid of the
access violation if the DLL creates a ofstream. It is at the last line
of the Windows Delphi file.

There have been many messages about similar problems with ofstream over
a few years. Is there any bug fixes for Turbo Explorer?

When I make a catch handler body empty the integrated debugger acts like
it isn't there. Thats not a big problem but it is strange.

Fraser.

Darko Miletic · Guest

Fraser Ross wrote:

Fraser Ross · Guest

As Remy said not long ago the DLL will be mapped into my EXEs address
space because I use LoadLibrary. That is why I get an access violation
in the EXE. Calling the default constructor of std::ofstream is only
ordinary code that I would not expect a problem with. I have tried
using the free store instead of the stack which made no difference.

Fraser.

Fraser Ross · Guest

"Darko Miletic"

Eike Petersen · Guest

Hi,

a long time ago I ran into a problem with the use of "atexit" in conjunction
with dynamically loading *and* freeing a DLL at runtime.

Recently I ran into a similar problem - again in conjunction with dynamically
loading and freeing a DLL. Just like in your case after using the streaming
facilities of the standard library and freeing the DLL at runtime, the program
crashes at program termination *after* leaving WinMain().

I know there is an error with "atexit" in the Borland implementation of the
C-Library which still is not fixed (see my old thread). It's quite possible the
current problems have a similar cause.

Old thread:

http://groups.google.de/group/borland.public.cppbuilder.language/browse_frm/thread/460b7e2b16137dc/0e5f32b8e1aeb028?lnk=st&q=&rnum=1&hl=de#0e5f32b8e1aeb028

It seems that some programmer at Borland tried to do something about the
problem, but after inspecting the source code of the RTL I'm under the
impression he didn't get to finish his job.

In source "startupd.c" you will find several references to a mysterious variable
called "_multidll". I didn't quite figure out how exactly the mechanism is
supposed to work, but I'm quite sure it doesn't work.

In line 159 the code reads something like this:

*** SNIP ***
if (_multidll && (share__dll_table = _create_shmem()) != NULL &&
share__dll_table->table[share__dll_table->ntables] !=
(MODULE_DATA *)-1)
{
share__dll_table->table[share__dll_table->ntables++] = mod_table;
}
else
{

_multidll = 0; /* set a flag that will force the
termination routine to call all of
the exit procs.
*/

/* Call all of the _INIT_ functions.
*/
_init_exit_proc(&_dll_table, 0);
}

*** SNAP ***

To my very surprise the implementation of the function '_create_shmem()' looks
like this:

*** SNIP **

MULTI_INIT *_create_shmem(void)
{
return NULL;
}

*** SNAP ***

When the program shuts down the following code from source 'startupd.c' starting
at line 229 will execute:

*** SNIP
/* The following loop calls the DLL's exit procedures.
* This is also done by _cleanup(), if the application exits
* with exit(); in that case, we won't do anything here, because
* all the exit procedures will be marked as "called". But if the
* application exits some other way, we must call the exit
* procedures here.
*/
if (!_multidll)
{

/* First call all entries in the atexit table for this DLL.
*/
if (__pCallAtExitProcs)
__pCallAtExitProcs();

/* Then call all of the _EXIT_ functions.
*/
_init_exit_proc(&_dll_table, 1);

#if defined(__MT__)
#if 0 /* Adding these two lines fixes a rare CG RTL memory leak.
It's commented out since it seems to adversly affect
other parts of the stream locking system.
*/
_cleanup_handle_locks();
_cleanup_stream_locks();
#endif /* 0 */
#endif /* __MT__ */

}
*** SNAP ***

As you can see the magic variable '_multidll' seems to be used here again -
however it will always be zero because '_create_shmem' will always return NULL
and therefore '_multidll' will always be reset to zero in the else branch of the
initialization quoted above.

Maybe I'm all on the wrong track, but something is definitely odd here. Maybe
the code for destroying certain static objects *within the RTL* gets called
twice? I'm not sure. The last time I spent over 8 hours debugging the RTL, but I
had to turn my attention back to my real project.

Best Regards
Eike Petersen

Fraser Ross wrote:

David Dean [CodeGear] · Guest

In article <459c5654$1 (AT) newsgroups (DOT) borland.com>,
Eike Petersen <epetersen-spam-protection (AT) gmx (DOT) net> wrote:

Fraser Ross · Guest

Does anyone agree that the of the dynamic RTL must be on or off
identically with all my projects? With my DLL project which has 2 LIB
projects linked I would expect its necessary there. When I compile my
EXE and DLL in debug mode it might be necessary. When I compile those
in release mode it is probably not necessary.

Fraser.