|
| C# program hangs while loading managed C++ wrapper to existing dlls. |
|
|
|
|
| Messages |
|
Related Types |
This message was discovered on microsoft.public.dotnet.languages.vc.libraries.
| Martin Serrano |
| GOOD ANSWER |
Hi,
Sorry for the crosspost, but I am not sure where this one goes...
I am trying to wrap existing unmanaged dlls with managed code. My
first example exposed a single class and one of its properties. I
then wrote a simple C# program to test it (I include it below).
About 1/3 of the time the program hangs (the rest of the time it works
as expected). When it hangs it has the stack trace I include below.
In trying to debug this I have determined that it is initializing the
static global cerr object. I have tried excising inclusion of the
iostream header from the unmanaged dlls, but alas, I cannot eliminate
it completely.
Am I encountering a fundamental incompatibility (iostream usage by
dlls and C#)? I have not seen any documentation that this is so. All
of the C++ code is compiled as multi-threaded debug.
Any help or suggestions would be appreciated.
Thanks,
Martin
0013ed47()
golib.net.dll!std::_DebugHeapString::_DebugHeapString(const char *
_Ptr=0x10050040) Line 115 C++
golib.net.dll!std::locale::_Locimp::_Locimp(bool transparent=false)
Line 155 C++
golib.net.dll!std::locale::_Init() Line 131 + 0x30 C++
golib.net.dll!std::locale::locale() Line 84 + 0xc C++
golib.net.dll!std::basic_streambuf<char,std::char_traits<char>
>::basic_streambuf<char,std::char_traits<char> >() Line 22 + 0x60 C++
golib.net.dll!std::basic_filebuf<char,std::char_traits<char>
>::basic_filebuf<char,std::char_traits<char> >(_iobuf *
_File=0x1005ef20) Line 135 + 0x24 C++
golib.net.dll!$E4() Line 11 + 0x16 C++
golib.net.dll!_initterm(void (void)* * pfbegin=0x1005e00c, void
(void)* * pfend=0x1005e0c4) Line 588 C
golib.net.dll!_cinit() Line 206 + 0xf C
golib.net.dll!_CRT_INIT(void * hDllHandle=0x10000000, unsigned long
dwReason=1, void * lpreserved=0x00000000) Line 158 + 0x17 C
golib.net.dll!_DllMainCRTStartup(void * hDllHandle=0x10000000,
unsigned long dwReason=1, void * lpreserved=0x00000000) Line 290 +
0x11 C
using System;
using golibnet;
namespace goadtest
{
/// <summary>
/// Summary description for Class1.
/// </summary>
class Class1
{
/// <summary>
/// The main entry point for the application.
/// </summary>
[STAThread]
static void Main(string[] args)
{
String name = "f:/m.xml";
GoAd_Net tst = GoAd_Net.CreateGoAd(name, true);
Console.WriteLine("Opened file {0}", name);
Console.WriteLine("Ad title {0}", tst.AdTitle);
tst.AdTitle = "foobar deluxe";
Console.WriteLine("Ad title {0}", tst.AdTitle);
}
}
}
|
|
|
| |
|
|
| |
| |
| Martin Fredriksson |
| GOOD ANSWER |
Hi Martin,
I think you have encountered one of the difficulties that can show it's ugly
face when
using interop.
When the runtime holds a memory area (by a function local reference) and you
pass this
memory to DLL/API code, it is no longer concidered beeing used by the
runtime and it will
therefore be memorycollected somtime in the future.
This could explain the randomness of your problem.
void AManageFunc()
{
X x = new X;
ApiCallPassingRefTox( x );
// x goes out of scope and is garbage collectable since there aren't any
references to it.
// the runtime does not care that you have given it to the API.
}
The solution to this is to grab hold of all such references until you know
that they aren't needed anymore.
Create a member variable for this and assign 0 to it when it's no longer
needed.
Check you code for things like this,
/Martin
"Martin Serrano" <Click here to reveal e-mail address> skrev i meddelandet
news:hh7B9.40130$QZ.7804@sccrnsc02...
[Original message clipped]
|
|
|
| |
|
|
| |
|
|
|
|
|
|
|
|
BootFX
Reliable and powerful .NET application framework. |
|
|
|
|
|
|
