declare, dylib access and crashing...

General
1

I’m accessing a dylib through a declare. I’m having success with some functions but with another function my app crashes with the following:

Exception Type: EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000038

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libsystem_c.dylib 0x930d4837 flockfile + 18
1 libsystem_c.dylib 0x930d61ca fputc + 37
2 Speclib.dylib 0x01738f58 CSpectroOperations::Spectro_LoadParameters() + 4274
3 Speclib.dylib 0x01716488 CSpectro::Spectro_Init0(int, long) + 1108

The dylib has an additional dylib which it presumably accesses and I put them both into the app’s Frameworks folder.

The path I am supplying to the declare is: @executable_path/../Frameworks/Speclib.dylib

I’ve been doing tons of research online to find the source of the crash and think it might be due to pathing but I’m mystified…

Anyone know what might be the problem here? I’m dead in the water at the moment….

thanks!

2

[quote=61231:@Steve Upton]I’m accessing a dylib through a declare. I’m having success with some functions but with another function my app crashes with the following:

Exception Type: EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000038

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libsystem_c.dylib 0x930d4837 flockfile + 18
1 libsystem_c.dylib 0x930d61ca fputc + 37
2 Speclib.dylib 0x01738f58 CSpectroOperations::Spectro_LoadParameters() + 4274
3 Speclib.dylib 0x01716488 CSpectro::Spectro_Init0(int, long) + 1108

The dylib has an additional dylib which it presumably accesses and I put them both into the app’s Frameworks folder.

The path I am supplying to the declare is: @executable_path/…/Frameworks/Speclib.dylib

I’ve been doing tons of research online to find the source of the crash and think it might be due to pathing but I’m mystified…

Anyone know what might be the problem here? I’m dead in the water at the moment….

thanks![/quote]

You should post the declare line and the signature of the function you’re calling.

3

OK,

From the SDK:

BOOL Spectro_Init(int nComPort,long lBaudrate);

Our declare:

declare function Spectro_Init lib kTheLib (port as integer, rate as integer) as integer

and I’m calling it by:

dim err as integer = Spectro_Init(0,0)

then…. boom!

As that what you are looking for?

4

[quote=61242:@Steve Upton]OK,

From the SDK:

BOOL Spectro_Init(int nComPort,long lBaudrate);

Our declare:

declare function Spectro_Init lib kTheLib (port as integer, rate as integer) as integer

and I’m calling it by:

dim err as integer = Spectro_Init(0,0)

then…. boom!

As that what you are looking for?[/quote]

Yeah. It looks correct, so I’m not sure what’s up. Is it possible that Spectro_Init(0,0) isn’t valid to initialize things?

5

no, it should be fine.

The SDK says it’s the first thing I’m supposed to call and their example code has it first as well.

I can call other functions and several of them work so I know I’m finding the main dylib OK.

One worry I have is the second dylib that we don’t call directly. I’m wondering if the path to the lib or the location of the lib is correct.

There’s precious little documentation on declares and the “@executable_path” is something I picked up years ago - no idea if I’m using it properly. (RB2011r3)

Is there another way of specifying the path that I should use? Should I put the dylibs right beside the executable itself (this solved a problem in the past on Windows for us).

In scouring the 'net I found a discussion entitled “Can one control where clang writes .gcda coverage files? (to avoid crash)” that mentions paths and the exact same crash (flockfile). It’s here It got me thinking that the dylib location or path we’re using might not be correct.

6

It’s really hard to guess at what’s wrong. I’m guessing you can’t redistribute the SDK, but can you post the binary somewhere so that I can take a look?

7

I’ll send a link to your email address immediately

8

I have the exact same error message and i was running down the web for several days now.

So, first, what comes in my mind when I see Steve’s code, is that the SDK declaration specifies a BOOL as return value, which I believe fits into one byte. Your declaration instead uses an integer as return type, which has on most platforms 4 byte length. Maybe this is causing the error.

Now, my error occurs as follows:

I have downloaded and installed the GNU SASL Lib (gsasl) for Mac OS X and I have no problems on calling the methods it provides using Declares. But at one point, the lib expects a pointer to a function as a callback, which looks like this:

int (*Gsasl_callback_function) (Gsasl *ctx, Gsasl_session *sctx, Gsasl_property prop);

where Gsasl_property is of type

typedef enum {…} Gsasl_property;

As enumerations are internally ints, I added a shared Method to my class similar to this:

Public Shared gsaslCb(ctx As Ptr, sctx As Ptr, prop As Integer) As Integer

But after passing this method via AddressOf to the lib, the application crashes with the error Steve described above when the lib tries to invoke the callback.

As this seems similar to Steve’s issue i post this here before opening a new conversation

9

OK, I made a really bad mistake resulting in a memory leak, it has nothing to do with the enumeration type…

10

[quote=61242:@Steve Upton]From the SDK:

BOOL Spectro_Init(int nComPort,long lBaudrate);

Our declare:

declare function Spectro_Init lib kTheLib (port as integer, rate as integer) as integer[/quote]

If the dylib is compiled for 64bit then a long parameter is an Int64, not an Integer/Int32.
And for a BOOL you have to use Byte/UInt8 because BOOL in Cocoa is a C char (1 bit).
So the declare should be:

declare function Spectro_Init lib kTheLib (port as int32, rate as int64) as byte