I have an Exception class in a DLL (let's call it A.dll), and in another DLL (let's call it B.dll) that links to A.dll, when an error occurs, it will throw an Exception (the one defined in A.dll). This is the Exception class:
UTIL_API is the _declspec(dllexport/import) stuff. Now, I want the application to handle the exception thrown. The application will link both A.dll and B.dll. When I catch the Exception, I call reportToDebug() function, that calls OutputDebugString( (*_message).data() );. But I got this runtime error: First-chance exception at 0x77e6d756 in game.exe: Microsoft C++ exception: Exception @ 0x0012fc7c. First-chance exception at 0x77e9bd4f in game.exe: 0xC0000005: Access violation reading location 0xfeeefeee. First-chance exception at 0x77e9bca3 in game.exe: 0xC0000005: Access violation reading location 0xfeeefeee. OutputDebugString faulted during output First-chance exception at 0x10032d55 (util.dll) in game.exe: 0xC0000005: Access violation reading location 0xfeeefee2. Unhandled exception at 0x10032d55 (util.dll) in game.exe: 0xC0000005: Access violation reading location 0xfeeefee2. game.exe is the application. edit: string is std::string Programmers are lazy people, they keep trying to find a way of doing so many things without moving.

Current project: A puzzle game. Homework.
% completed: ~10%. ~80%
Status: Active. Active. [edited by - alnite on May 17, 2003 3:12:06 PM]

IIRC, throwing exceptions across a DLL boundary is a Bad Thing. Windows, at least, will object horribly if you try to throw an exception out of a callback function. However, MFC seems quite happy to throw exceptions at you, so I''m not entirely sure about that one...


As for your runtime errors...your Exception class is holding string* members. Are these string objects declared as local in the function that throws? If so, they will have passed out of scope as soon as it reaches a throw statement.

OK, so I was wrong about that....

But it does look like the problem is copy constructors. Exceptions are thrown ''by value'', so if the default copy constructor does a shallow copy of your pointers, then they get deleted by the first object, Bad Things Will Happen. Make a copy constructor that allocates its own resources, then does a ''deep copy'' of the string objects.

actually, tr0n is right..

dont throw an exception from a DLL if you can avoid it ...
You can throw it , but it causes problems with some methods. I honestly dont know why, but try not to do it. Also causes clean up problems with the DLL throwing the exception.

You guys were right, I forgot to write the copy constructor. I fixed it, but the problem is still there.

So, I believe it ha something to do with throwing an exception from DLL. I created a dummy function in game.exe, and threw an exception from there. It worked fine. But when I threw an exception from a DLL, it gave me those error messages.

Probably it''s the local and global memory allocation. DLL is on a separate process, thus its memory is ''protected'' from outside. When game.exe tried to access _message and all the string (which was accessible to the DLL only), the error was raised.

I tried to search on google about this but it gave no helpful results. MSDN didn''t say anything about it also (and you know its search engine sucks). I looked on GlobalAlloc, and there is a note:

quote:
Note The global functions are slower than other memory management functions and do not provide as many features. Therefore, new applications should use the heap functions. However, the global functions are still used with DDE, the clipboard functions, and OLE data objects.

Well, I don''t mind the slow thing since this is an exception anyway, and my game will eventually exit, but it didn''t say anything about DLL or global memory page. So I was kind of doubt and unsure using it for this particular situation.

Also, it said to use heap functions instead (it''s a clicky). But the heap functions (page) said:

quote:
The heap functions enable a process to create a private heap, a block of one or more pages in the address space of the calling process

But I don''t want it to be private!

quote: Original post by jwalker
dont throw an exception from a DLL if you can avoid it ...
You can throw it , but it causes problems with some methods. I honestly dont know why, but try not to do it. Also causes clean up problems with the DLL throwing the exception.

Maybe I catch the Exception from within the DLL itself, not outside