DLLs and Sharing Memory

I'm not even sure if this is actually considered 'Shared Memory', and
that's partly why Googling this particular problem of mine has failed
me for the most part. Please read the following and maybe you can
determine the problem I'm trying to solve, and possibly point me in
the right direction:

I have an application, and a DLL. The application was linked to the
DLL via a .lib file, and was accessing the exported functions just
fine. One particular example of the relationship was this:

void _stdcall GetHosts(vector<string> * vszHostsD);
// In which the DLL would require a pointer to a vector<string> as
input, and modify its contents.

// And the application would call this function in the appropriate
way:
vector<string> * vszHosts;
GetHost(vszHosts);
MessageBox(...vszHosts.at(0).c_str()...); // The contents of the
vector were filled correctly

Then I noticed that on certain systems (particularly, WinXP SP1), the
program failed to run. So I researched a bit, and found two
solutions. 1. Add the msvc8 DLLs to my distribution, and 2. change my
compiler's configuration. I opted for the latter, because my program
is written entirely in Win32 API and meant to be a very small
executable. My original configuration was this:

Configuration Properties -> C/C++ -> Code Generation -> Runtime
Library == /MD

I followed some advice, and changed this value to /MT

Now, the program runs on other systems, but occasionally crashes when
the DLL functions are called. When debugging on my system (WinXP
SP2), the application always breaks. It looks like its having trouble
allocating memory correctly, or more likely, modifying memory from the
calling process. I suppose this makes sense.

I am not entirely sure if this qualifies as a 'Shared memory' problem,
but basically I'd like those 3 lines of code above to work, on all
systems, without needing to include any extra files. Code changes and
compiler configurations are not a problem at all.

Can anyone point me in the right direction? Thanks in advance,

Jimmie Tyrrell

Jimmie
Tue Jan 08 15:52:06 CST 2008

I meant to include some error messages, my apologies for not
remembering to do this before:

This occurs when GetHosts is called. Runtime Library is set to /MT.
The function in my DLL, does not actually process anything, its empty

void _stdcall GetHosts(vector<string> * vszHostsD) {
return;
}

And throws:

First-chance exception at 0x7e41b5b1 in UpConfig.exe: 0xC0000005:
Access violation writing location 0x00000001.
A buffer overrun has occurred in UpConfig.exe which has corrupted the
program's internal state. Press Break to debug the program or Continue
to terminate the program.

When I call this:

vector<string> * vszHosts;
GetHost(vszHosts);

Igor
Tue Jan 08 16:08:43 CST 2008

Jimmie <oskard@gmail.com> wrote:
> I have an application, and a DLL. The application was linked to the
> DLL via a .lib file, and was accessing the exported functions just
> fine. One particular example of the relationship was this:
>
> void _stdcall GetHosts(vector<string> * vszHostsD);
> // In which the DLL would require a pointer to a vector<string> as
> input, and modify its contents.

This can only work if both the EXE and the DLL are compiled with the
same version of the same compiler using the same options, and linked to
the same flavor of CRT DLL. It won't work if you link to CRT statically.

> // And the application would call this function in the appropriate
> way:
> vector<string> * vszHosts;
> GetHost(vszHosts);
> MessageBox(...vszHosts.at(0).c_str()...); // The contents of the
> vector were filled correctly

This can't possibly compile. Did you mean

vector<string> vszHosts;
GetHost(&vszHosts);

?

> My original configuration was this:
>
> Configuration Properties -> C/C++ -> Code Generation -> Runtime
> Library == /MD
>
> I followed some advice, and changed this value to /MT

Wrong move. /MT means linking to CRT statically, which results in EXE
and DLL each having a separate copy of memory manager. Memory allocated
in one module cannot be freed in another. /MD was a correct choice
(still better choice would be to redesign the DLL interface so it
doesn't require passing resource ownership between modules).
--
With best wishes,
Igor Tandetnik

With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925

Jimmie
Tue Jan 08 16:31:17 CST 2008

On Jan 8, 5:08 pm, "Igor Tandetnik" <itandet...@mvps.org> wrote:
> Jimmie <osk...@gmail.com> wrote:
> > I have an application, and a DLL. The application was linked to the
> > DLL via a .lib file, and was accessing the exported functions just
> > fine. One particular example of the relationship was this:
>
> > void _stdcall GetHosts(vector<string> * vszHostsD);
> > // In which the DLL would require a pointer to a vector<string> as
> > input, and modify its contents.
>
> This can only work if both the EXE and the DLL are compiled with the
> same version of the same compiler using the same options, and linked to
> the same flavor of CRT DLL. It won't work if you link to CRT statically.

Yes, I thought I did that correctly. But now, on my XP SP1 machine I
get this error:

"This application has failed to start because the application
configuration is incorrect. Reinstalling the application may fix this
problem."

My XP SP2 runs this app just fine.


>
> > // And the application would call this function in the appropriate
> > way:
> > vector<string> * vszHosts;
> > GetHost(vszHosts);
> > MessageBox(...vszHosts.at(0).c_str()...); // The contents of the
> > vector were filled correctly
>
> This can't possibly compile. Did you mean
>
> vector<string> vszHosts;
> GetHost(&vszHosts);
>
> ?

Yes, my mistake :) I wrote this from a virtual machine and do not
have clipboard sharing enabled :)

> > My original configuration was this:
>
> > Configuration Properties -> C/C++ -> Code Generation -> Runtime
> > Library == /MD
>
> > I followed some advice, and changed this value to /MT
>
> Wrong move. /MT means linking to CRT statically, which results in EXE
> and DLL each having a separate copy of memory manager. Memory allocated
> in one module cannot be freed in another. /MD was a correct choice
> (still better choice would be to redesign the DLL interface so it
> doesn't require passing resource ownership between modules).

I think I understand. This would actually improve the performance of
my application in many ways. I think I will try this later on
tonight.

Thanks for you help again, Igor.

Scott
Tue Jan 08 16:31:14 CST 2008

"Jimmie" <oskard@gmail.com> wrote in message
news:63fc9387-e5b2-4281-b629-516b35629a49@e6g2000prf.googlegroups.com...
> I'm not even sure if this is actually considered 'Shared Memory', and
> that's partly why Googling this particular problem of mine has failed
> me for the most part. Please read the following and maybe you can
> determine the problem I'm trying to solve, and possibly point me in
> the right direction:
>
> I have an application, and a DLL. The application was linked to the
> DLL via a .lib file, and was accessing the exported functions just
> fine. One particular example of the relationship was this:
>
> void _stdcall GetHosts(vector<string> * vszHostsD);
> // In which the DLL would require a pointer to a vector<string> as
> input, and modify its contents.
>
> // And the application would call this function in the appropriate
> way:
> vector<string> * vszHosts;
> GetHost(vszHosts);
> MessageBox(...vszHosts.at(0).c_str()...); // The contents of the
> vector were filled correctly
>
> Then I noticed that on certain systems (particularly, WinXP SP1), the
> program failed to run. So I researched a bit, and found two
> solutions. 1. Add the msvc8 DLLs to my distribution, and 2. change my
> compiler's configuration. I opted for the latter, because my program
> is written entirely in Win32 API and meant to be a very small
> executable. My original configuration was this:
>
> Configuration Properties -> C/C++ -> Code Generation -> Runtime
> Library == /MD
>
> I followed some advice, and changed this value to /MT
>
> Now, the program runs on other systems, but occasionally crashes when
> the DLL functions are called. When debugging on my system (WinXP
> SP2), the application always breaks. It looks like its having trouble
> allocating memory correctly, or more likely, modifying memory from the
> calling process. I suppose this makes sense.
>
> I am not entirely sure if this qualifies as a 'Shared memory' problem,
> but basically I'd like those 3 lines of code above to work, on all
> systems, without needing to include any extra files. Code changes and
> compiler configurations are not a problem at all.
>
> Can anyone point me in the right direction? Thanks in advance,


It's not a "shared memory" problem, it's a "shared vector" problem. The
only way to let exe and dll share the same vector library is to use /MD.
And using /MD means you have to have the msvc8 DLLs installed: That's where
the sharable vector library is located!

Your other option is to avoid passing library objects across the exe/dll
line. You could change the code to pass char arrays.

--
Scott McPhillips [VC++ MVP]

David
Tue Jan 08 16:44:48 CST 2008

Igor Tandetnik wrote:
> Wrong move. /MT means linking to CRT statically, which results in EXE
> and DLL each having a separate copy of memory manager. Memory allocated
> in one module cannot be freed in another. /MD was a correct choice
> (still better choice would be to redesign the DLL interface so it
> doesn't require passing resource ownership between modules).

... after which it should be possible to use /MT.

--
David Wilkinson
Visual C++ MVP

Igor
Tue Jan 08 16:59:16 CST 2008

Jimmie <oskard@gmail.com> wrote:
> On Jan 8, 5:08 pm, "Igor Tandetnik" <itandet...@mvps.org> wrote:
>> This can only work if both the EXE and the DLL are compiled with the
>> same version of the same compiler using the same options, and linked
>> to the same flavor of CRT DLL. It won't work if you link to CRT
>> statically.
>
> Yes, I thought I did that correctly. But now, on my XP SP1 machine I
> get this error:
>
> "This application has failed to start because the application
> configuration is incorrect. Reinstalling the application may fix this
> problem."
>
> My XP SP2 runs this app just fine.

Do you have msvcrt8.dll actually installed on that SP1 machine?
--
With best wishes,
Igor Tandetnik

With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925

Jimmie
Wed Jan 09 08:54:42 CST 2008

On Jan 8, 5:59 pm, "Igor Tandetnik" <itandet...@mvps.org> wrote:
> Do you have msvcrt8.dll actually installed on that SP1 machine?

No, its nowhere to be found.

I can rewrite the libraries as you suggested though, it seems that'll
be fairly simple.

Thanks again everybody