Annoying error message on exit

[Destin Elam]

Hi!

I'm having a strange issue with my DLL when used with FFI. It loads just fine and
all the native functions seem to work without any problems when called via FFI.

However, whenever Ruby reaches its exit point, the following message appears:

"This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information."

Does anyone have a clue why this might be happening? Supposedly, this message appears on Windows when abort() is called somewhere.

Here's some info that may be useful:
- I'm running the one click installer version of Ruby 1.9.3 on Windows.
- The DLL file in question consists of wrapper code for a C++ library I've made. Said library relies on a bunch of other 3rd party libraries.
- I've made a minimal test DLL that doesn't link to any other 3rd party libraries and that one doesn't trigger the above error message at exit.

Any help and/or pointers would be greatly appreciated as I've tried to fix this issue for days!

Thanks!

[Daniel Berger]

Destin, it's more likely there's a bug somewhere in your code than an explicit abort() call, though the fact that it only happens at exit is odd. Do you have any exit handlers setup that might be causing problems?

Regards,

Dan 

[Destin Elam]

I, too, believe it's something I screwed up as the other minimal DLL doesn't display the message.
What has me stumped, though, is that the following code is enough to trigger the issue:

require 'ffi'

module Test

#simply loading the dll is enough for it to happen
ffi_lib 'my_wonky_dll.dll'

end

In case it's useful to know, the DLL seems to work when used directly in C++.

I'm not using any exit handlers, as far as I am aware, but perhaps one of the third party I'm using libraries might? I'll definitely have a closer look at this -- thanks a lot!

[Destin Elam]

Just for clarification: the DLL seems to work without triggering any weird messages or errors when used directly in C++!

[Daniel Berger]

On Tuesday, August 11, 2015 at 7:11:13 PM UTC-6, Destin Elam wrote:

Just for clarification: the DLL seems to work without triggering any weird messages or errors when used directly in C++!

Is there a way to generate a minimum bit of code you can show that replicates the problem?

Dan 

[Destin Elam]

Absolutely -- will do, so as soon as I get back home! Really appreciate that you are willing to try and help me. :)

[Destin Elam]

OK, here it is in kind of a pseudo code format for easier readability.. or so I hope. If not, I apologize beforehand!

Header file, dllheader.h:

#ifdef    __cplusplus
extern "C" {
#endif

//ADDAPI is simply a __declspec(dllexport) in this case.
void* ADDAPI createLibMain();

int ADDAPI helloWorld();

#ifdef    __cplusplus
}
#endif

The cpp file:

#include "dllheader.h"
#include "mycpplibraryheader.hpp"


void* createLibMain()
{
    return new CPPLibraryNativeObject();
}

int helloWorld()
{
    return 1337;
}

I wouldn't normally return a void pointer to as a return value, but did so here to keep things minimal.

If you can't spot anything strange with my code, I can also try and strip away the various third party libraries I use one by one until the message stops appearing, too.

Anyway, thanks in advance!

[Daniel Berger]

Are you sure it should be using the default calling convention? What happens if you set it to :stdcall?

It may not have anything to do with it, but I thought we should at least eliminate the possibility.

Dan 

[Destin Elam]

I'll make sure to try it out as soon as I get back home!
Here's hoping that this is the culprit..

[Destin Elam]

Ack, still no luck!

Tried adding "ffi_convention :stdcall" to the ruby code, but still am getting the message.
I also tried to add __stdcall to my functions in the C++ code so it could be used conjunction with ffi_convention without success. :'(

On Thursday, August 13, 2015 at 12:55:42 AM UTC+9, Daniel Berger wrote:

[Destin Elam]

OK, so I finally managed to solve it. Well, kind of at least. It turns out that dynamically linking to the third party libraries, as opposed to statically like I was before, eliminated the issue.
No real clue why since I'm a rookie when it comes to building DLLs but there you have it in case anyone is interested!

[Charles Nutter]

Interesting. So were the symbols not being exported in the static build case? Perhaps there's some build options you can use when statically linking to the other library to re-export its symbols?

- Charlie

[Destin Elam]

Hi!

I think the symbols were exported since I was able to call the functions in my DLL through attach_function, seemingly without any problems.
Looking at the .def file generated via --output-def when building with g++ (MinGW), the functions of the various libraries seem to have been exported as well.
I may be under some misconception about things, though. Again, I'm new to building DLLs so please bear with me if I assume something that is outright wrong!

Hmm, yeah, I think you're right about me not getting the build options right when building the third party libraries.
I intend on having a closer look at it one day for sure. Many thanks, Charles! :)