EXC_BAD_ACCESS when building for macOS (Release only, Debug works)

[dimitre]

I've just noticed ofxNDI is not working when compiling with Release instead of Debug on macOS (not tested on ubuntu yet) Steps to reproduce: try to compile example-receiver, selecting release in XCode

error

Thread 1: EXC_BAD_ACCESS (code=1, address=0x1)

in ofxNDIreceive.cpp, line 687

            pNDI_recv = p_NDILib->recv_create_v3(&NDI_recv_create_desc);

[leadedge]

OK. I see that line 687 is the master branch. I haven't updated that yet with the recent corrections. Does the same happen with the testing branch? Try that first.

Is the sender OK with debug and release?

Otherwise the library pointer could be causing the problem. Check for null pointer in case the dynamic loader isn't working. If it's OK, try installing the NDI runtime from . I don't have XCode to test it.

[dimitre]

I forgot to mention, I'm already on testing branch.

Sender runs great in debug / release (if I comment out sprintf_s) Receiver runs on debug and crashes on release.

Not sure if it helps but here is the output

NDI runtime location libndi.4.dylib

ofxNDI example receiver - 32 bit
NDI SDK APPLE 19:20:53 Sep 16 2019 4.0.1 (http://ndi.tv/)

[leadedge]

I can't see why debug/release should be any different.

I started to use std::string instead of sprintf_s for on-screen messages. It could be the problem.

Have a look through and disable all the on-screen messages.

The line you refer to is 689 in the testing branch. Was 687 a typo?

[dimitre]

yes a typo, line 689 checking now. I think it has to be with libndi.4.dylib itself. I'll try to update to 4.5 here and see if it works it seems it happens in other places too https://github.com/Palakis/obs-ndi/issues/405

[leadedge]

From what you say, there seems to be a problem with the NDI library. To investigate this, they would need a repeatable fault with XCode build of their examples which I cannot do.

Meanwhile I made sure the include files in the testing branch were up to date and put in some more function checks to make sure the library was loaded. This should be OK for you to rebuild.

Check to see that the NDI dll is not in the application or addon folders. It is not needed with dynamic loading but would be loaded if it was there and it might be an older version.

[dimitre]

Just pulled changes and I've got errors trying to compile sender and receiver

const NDIlib_source_t* ofxNDIreceive::FindGetSources(NDIlib_find_instance_t p_instance,
    uint32_t* p_no_sources,
    uint32_t timeout_in_ms)
{
    if (!bNDIinitialized) return false;

Cannot initialize return object of type 'const NDIlib_source_t *' with an rvalue of type 'bool'

[leadedge]

OK no problems. Just a bit hasty with cut and paste. It's strange that the error was not reported when I tested it. Replace with -

if (!bNDIinitialized) return nullptr;

It's not addressing the primary problem though. It might have something to to with the dynamic loading dll which is installed by the runtime installer. If this was compiled debug instead of release it could be causing the problem.

Also if you can compile the NDI examples it might tell us more. The C++ receiver example does not use dynamic loading.

To confirm that, I updated the most recent dll files. I am not sure if you are Win32 or x64 but copy the one you need to to your application folder. Then the dll should be found and used instead of the runtime. You might have to trace to confirm that happens. If there is any difference, it will point to the dynamic load runtime.

[dimitre]

I didn't find SDK examples but I did something else which solved here running examples from https://github.com/nariakiiwatani/ofxNDI I've noticed they work both in release and debug the difference is the include files, I think you use a more recent version. Using older include makes it work on release too

Copyright(c) 2014-2019 NewTek, inc - runs OK Copyright(c) 2014-2020 NewTek, inc - doesn't run receiver on Release

[leadedge]

Well spotted. I looked through all the files and updated from recv_capture_v2 to recv_capture_v3 in ofxNDIreceive.cpp. Try this change with the most recent include files first.

If there is still a problem, it seems that you could go back to the v2 functions and the 4.0 include files. The changes are easy to find by search on "Update to 4.5".

You have to install the NDI SDK to get the examples. I also found that only the Windows dlls were installed with the SDK, but that doesn't matter now that we are using dynamic loading.

[dimitre]

I've pulled the changes and no luck with example-Receiver (Release)

[leadedge]

OK that isn't the problem then. I am not sure how I can trace this this without a repeatable fault.

Since you have found that it builds OK release with the 4.0 include files, that is the only solution I can suggest.

If you install the NDI SDK, there are quite a few examples. But for me, after a Windows installation, there is only one example specific to Xcode and it is not a receiver. The others have Visual Studio projects but the source might build with XCode. If you can reproduce the problem with any of these, the NDI people might be able to trace it.

[leadedge]

I have made a change that is a long shot.

From what I can find, EXC_BAD_ACCESS can occur if members of a structure are not initialized. Various discussions suggest that Debug mode initializes variables but Release does not.

The existing code should be OK, but I have changed it so that every member of the NDIlib_recv_create_v3_t structure is individually initialized to make sure.

Beyond that I can't suggest anything else unless there is something that clearly comes to light.

[dimitre]

I've just pulled and unfortunately we have the same error I had to change FALSE to false to compile too. I'm pretty sure NDI 4.5 SDK is the issue, and I think it is confusing the way they handle versions too, both for dylib and the code. thank you for all the effort you put in this issue

[leadedge]

OK I don't think I can do any more with this then.

I changed false to FALSE just in case it was required to be some particular value. The NDI library uses TRUE/FALSE throughout. That's now confirmed as not necessary.

It seems that the only solution for you is to use the older header files and function definitions. It's fortunate that you discovered this.

I will leave the updated code and then we can see if anybody else has problems with XCode.

[leadedge]

As you will have found, I have updated Master from Testing. I don't have the resources to resolve this issue, but will leave it open for a while and we will see what happens.

[dimitre]

I'm now merging your changes to my fork so I can downgrade files and use here, I've just noticed the examples source code are duplicated, ofApp.h, ofApp.cpp and main.cpp are both inside and outside src folder.

[leadedge]

Somehow the example files got out of place at some point. I will sort this out later but won't get up to it for a little while.

[leadedge]

Duplicate files are now removed

[dimitre]

Closing this one too. not an issue anymore on most recent versions