memmgr failure on AnsiString allocation in dll

[Leo Siefert]

According to the comment added to the top of a dll project by the
expert, adding memmgr.lib to both the dll and the calling exe is
supposed to allow safe allocating and passing of AnsiStrings between
the dll and the exe.

The following report includes a small demo project group showing that
this does not appear to work correctly in debug builds if a moderately
large char* is assigned in a dll to an AnsiString reference parameter.

Report No: 59801 Status: Reported
memmgr.lib fails with large AnsiString allocation in dll
http://qc.codegear.com/wc/qcmain.aspx?d=59801
QCWIN:Defect_No=59801

- Leo

[Tomohiro Takahashi]

Hi,

I added a comment about sharing memory manager between EXE and DLLs, which are built with
C++Builder.

Regards,
CodeGear
KEN <TAKAHASHI, Tomohiro>

[Tomohiro Takahashi]

Hi, Leo-san

I post an additional comment about passing parameter and its type.

Regards,
KEN <TAKAHASHI, Tomohiro>

[TAKAHASHI, Tomohiro]

Hi, Leo-san

Could you please try to add both 'sharemem.obj' and 'memmgr.lib' to all projects,
and rebuild .EXE and .DLLs?

I think that linking 'sharemem.obj' is sharing 'borlndmm.dll'.

[Leo Siefert]

TAKAHASHI, Tomohiro wrote:

>Could you please try to add both 'sharemem.obj' and
>'memmgr.lib' to all projects, and rebuild .EXE and .DLLs?

Actually, adding sharemem.obj to the exe and the dll does _appear_ to
solve the problem, but I am reluctant to use an undocumented hack in
production code. Actually, as I stated earlier, my problem can be
solved by simply building the dll as documented with memmgr.lib linked
to it as long as I build the dll without debug information linked in.

>I think that linking 'sharemem.obj' is sharing 'borlndmm.dll'.

That's not what the documentation says. There is _Delphi_
documentation that says to add ShareMem to the uses section but in all
other cases this translates to adding the appropriate header in C++ -
I have never had to search for an undocumented obj file before.

Besides the rather clear documentation added to the top of every dll,
there is this page:

ms-help://borland.bds5/devwin32/staticruntimelibraries_xml.html

listing the static libraries and obj files that can be linked into C++
projects (the obj files are almost always handled by the IDE). The
page shows:

>memmgr.lib Import library for BORLNDMM.DLL

That means that the entire purpose of memmgr.lib is to make sure that
your app uses borlandmm.dll. This has been the documented solution for
as long as I have used C++ Builder, and the documentation is
prominently presented.

Are you suggesting that there is no bug because there is another
undocumented hack that appears to work? Are you suggesting that the
way of sharing memory has changed (which would break imported apps)
but that it is being kept secret?

- Leo

[Tomohiro Takahashi]

Hi, Leo-san

I think it is documentaion bug.
So, we must link both 'sharemem.obj' and 'memmgr.lib' to use borlndmm.dll externally
when we do not use Dynamic RTL(cc32xxmt.dll).

Regards,
KEN <TAKAHASHI, Tomohiro>

Leo Siefert wrote:
>
> >I think that linking 'sharemem.obj' is sharing 'borlndmm.dll'.
>
> That's not what the documentation says. There is _Delphi_
> documentation that says to add ShareMem to the uses section but in all
> other cases this translates to adding the appropriate header in C++ -
> I have never had to search for an undocumented obj file before.

snip

[Leo Siefert]

Tomohiro Takahashi wrote:

>I think it is documentaion bug.

I doubt it. Works as documented in release mode.

What would be the purpose of suddenly introducing a breaking change?
If it's intended to be used in the same way, why would they not simply
make a lib out of sharemem and rename it memmgr.lib?

>So, we must link both 'sharemem.obj' and 'memmgr.lib' to use
>borlndmm.dll externally when we do not use Dynamic
>RTL(cc32xxmt.dll).

Not true either. If I do link sharemem.obj into my projects then
memmgr is not necessary. As I said, this is an undocumented hack, and
quite possibly only works because the test project I used it in was
minimal.

- Leo

[dhoke]

(in bds2006) Due to (distributed) library build configuration, I don't think
this can work. I believe in a debug build the separate projects/modules
will each wind up with their own memory managers, and thus heaps, thus
making it fairly impossible to pass allocations across boundaries, at least
if you want to alloc on one side of boundary and free on the other.

See QC50159 for some possibly pertinent information.

(Sorry I didn't think about this sooner when I first saw this thread.)

"Leo Siefert" <lIHATESP...@senate.michigan.gov> wrote in message
news:becfu39eudstn8jaj...@4ax.com...