Console App - Works in IDE, on Linux and Mac but program terminates badly on Windows

Targets Windows
1

I have a strange issue with a console app.

I have compiled the PolarSSL cryptography library and made a small C DLL which wraps up a couple of functions to allow me to create ripemd160 hashes and create an Elliptic Curve public key from a 256 bit Elliptic Curve private key. I’m doing some programs that work with Bitcoin and this is the basic functionality required to create and work with Bitcoin addresses.

I compiled it with MinGW on Windows and gcc on Linux / Mac - everything worked as expected apart from when I use it as a windows console app.

When I call a specific function from the dll/so/dylib inside the Xojo consoleapp it all works but when the program completes and exits a crash is reported on Windows. It only happens when the program completes, there are no errors when it’s running.

Note - This does not happen when I successfully run the exact same program within the IDE on Windows by clicking the big green ‘Play’ button, it only happens when I run it from the command line as a built application. This strikes me as being very odd behaviour.

In order to rule out a problem with the DLL I wrote a small C program to call the DLL and that also had no problems on Windows.

I isolated the specific part of the Polarssl library which causes this to happen.

It happens when I call the ‘ecdsa_init’ function ( https://polarssl.org/api/ecdsa_8h.html#a70bf12fe3c9062d5ee306378d94f8d67 ) within my compiled DLL. This function prepares the data structure which holds details about the elliptic curve being used. It’s quite complex in that it uses various data types including a custom bignum library which comes with the PolarSSL library.

When the same console program runs in the IDE it does not crash on termination, when it runs from the windows command line this is what happens :

I have a feeling it’s something to do with cleaning up memory before the program exits but that’s just a hunch.

Any ideas ?

I can post source code and samples if required. I have only tested this in console apps but I’ve tested it on all three platforms.

I am almost certain that this is nothing to do with PolarSSL - it’s a widely used professional commercial library which we’re allowed to use for open source projects.

I find it a little bizarre that the program completes without any issue when executed inside the IDE on Windows but not when it’s executed from the command prompt - what’s the difference between the two ?

2

I’ll add to this, the full test in the popup error message is as follows :

Problem signature:
Problem Event Name: APPCRASH
Application Name: crossplatform.exe
Application Version: 1.0.0.0
Application Timestamp: 53da569b
Fault Module Name: libgcc_s_dw2-1.dll
Fault Module Version: 0.0.0.0
Fault Module Timestamp: 525049a5
Exception Code: 40000015
Exception Offset: 000148fe
OS Version: 6.1.7601.2.1.0.256.48
Locale ID: 2057
Additional Information 1: d378
Additional Information 2: d378294c5963525b1e87790f5b22d9c7
Additional Information 3: 33d1
Additional Information 4: 33d1005dafc2818aba005715386030df

Read our privacy statement online:
http://go.microsoft.com/fwlink/?linkid=104288&clcid=0x0409

If the online privacy statement is not available, please read our privacy statement offline:
C:\Windows\system32\en-US\erofflps.txt

3

I think you’re right about it being memory management. I’ve had crashes in the past that have been solved by explicitly breaking cyclical references in order to allow destructors to fire and memory to be freed up. They’re hard to track down. It’s mostly trial and error. There are a lot of timing differences in running the app from the IDE and running the built app. The lags introduced by running from the IDE seem to hide these problems. I’m not sure why.

4

The thing is, there’s no destructors here, it’s just plain old C with pointers passed around inside the functions.

I forgot to mention that in addition to the ecdsa_init function I’m also calling the ecdsa_free function which goes through the intialised context variables one by one freeing them up.

It makes no difference though, one call to the init function guarantees a crash when the program eventually terminates no matter what I do.

I’ll do some meddling around to introduce some delays before the program terminates calling doevents to see if that makes any difference.

5

I’ve solved this issue. This program I’ve been working on is a test for all my DLL’s.

I’m compiling some DLL’s with the MinGW C compiler then testing them by calling each function inside Xojo and ensuring the correct results are returned, etc.

Due to this there are lots of declares to DLL’s, some of which aren’t used as they’re older tests from when I first started this process - this proved to be the crux of the problem.

As I rewrote the DLL’s I changed the parameters and it seems that there were still some declares lying around which referred to old versions of the DLL with different parameter sets.

I had a mixture of declares and soft declares which didn’t help the issue and made results inconsistent as soft declares would only cause an issue when i used the ‘Method’ which contained the declare.

After spending many hours going through this I removed all the old stuff and rechecked every declare function and the issue has now disappeared.

I’ll be more vigilant about the DLL’s in future.

I initially thought this was a C compiler related build issue but it turns out that was working fine all along.

6

@Neil McAliece can you tell me how you make call to c dll function? I am also trying to call c dll function from my xojo project but i am not able to do it. I am searching for it. exactly where should i declare dll function in xojo desktop app? it might be silly questions but please help me sir…

7

I tend to put my ‘declare’ or ‘soft declare’ statements in different methods for each external dll/dylib/so function I’m declaring, sometimes I’ll put them in a method inside a module.

I ‘wrap’ them up so they appear within Xojo as regular methods, you can then completely forget that they’re external and treat them like any other method you’ve programmed in Xojo.

I’ve only been writing console apps so far but I doubt it will make any difference with GUI apps.

8

http://www.xojo.com/blog/en/2014/01/accessing-net-code-from-xojo.php