threadedFunction() throws EXC_BAD_ACCESS

[dboleslawski]

Oi, I spent the last few hours trying to fix this bug, but sadly I don't really have any idea how to tackle this problem... Hopefully you can enlighten me :)

I'm trying to run the example_client_hello_world without any additions. It show the program (black window) but jumps right back to Xcode and shows this error:

Any ideas what could fix this? Thanks in advance!

Btw. I'm doing this on OSX 10.11.3...

[robotconscience]

Checking into this right now! Can you provide any more details on your setup? It's running fine for me.

Did you change what server you're connecting to? Is your internet on? Anything else of note? Let me know, we'll figure it out!

[robotconscience]

Let me know what version of OF you're using as well

[dboleslawski]

Wow, nicest and fastest reply I've ever got on the internet!

This is currently my setup: MacBook Pro (Retina, Mid 2012) / OSX 10.11.3 Xcode 7.2.1 OF v0.9.1

I'm connected to my WiFi, the internet is working and I didn't change the server I'm connecting to...

[dboleslawski]

Weirdly enough using the clean function (Product -> Clean) just fixed this problem with the hello_world example. Huh.

But as soon as I started to try this with my own server in my local network (using a ESP8266, tested and working) it showed up again. I only changed the lines as recommended in the comments of the example:

At least it shows in the console that it created the connection successfully. Yay. Sadly cleaning and rebuilding doesn't fix this problem...

[robotconscience]

Super weird! I unfortunately don't have the hardware, but it's working for me with a local nodejs server as well as a few different ones on the 'net. Hm! Can you try inspecting the "context" object where that crash is?

Tried looking at libwebsockets, and it does look like some folks did have problems with the function your app is crashing on. You could try updating the underlying libwebsockets library?

To confirm, does it crash on any server, or just the ESP8266?

[dboleslawski]

I tried a bunch of different servers and rolled a localhost node.js server and they worked flawlessly. The EXC_BAD_ACCESS shows only up, when I try to connect to a server in my local network, even with different WiFI-APs. At least we kinda know now what the problem is. Heh.

I'm currently trying to compile the libwebsockets library to update the underlying lib as you suggested and will report asap if I stumble upon something new.

[dboleslawski]

Oh well, seems like the newest libwebsockets lib is not playing well with ofxLibwebsockets:

Any idea what could fix this? If not I'm just going to get a lil' creative and write a little node.js script that sits between my ofxApp and the ESP8266.

Btw.: using the directions for compiling on the readme.md I ran into some problems, mostly because Apple removed the OpenSSL header files with El Capitan. Installing the OpenSSL using the universal option and linking it properly fixes these problems easily.

brew install openssl --universal
brew link openssl --force

Agian, thanks a lot for all the help!

[robotconscience]

Ah geez, looking like they changed some stuff in lws, so will have to look again when it comes to bringing in the new version. Sorry! Will be a bit before I can fully update, but I may be able to push an OS X only branch in the near future.

If you got it compiling, you could use their test client app (compiles along with the library) and see if it has the same problems! I'll try to see what's up with the bad access, shouldn't happen even if it can't quite see the server. Let me know if you have any more luck, sorry it's been a drag!

[dboleslawski]

Well well, seems like their test client app doesn't like my ESP either. Heh.

I'll see if I can find a quick workaround for this problem since my deadline is pretty soonish. If I find anything, I'll let you know for sure! Thanks for all the help and this wonderful lib!

[mattfelsen]

Hey @dboleslawski I started seeing this problem when I added the reconnect to ofxLibwebsockets::Client. While I don't think that there's anything in particular that's wrong with the reconnect code, turning it off seems to avoid this weird issue with the lws context. Can you try turning the reconnect off and see if that helps your situation? You can do it in one of two ways:

Use an ofxLibwebsockets::ClientOptions object when connecting:

ofxLibwebsockets::Client client;
auto options = ofxLibwebsockets::defaultClientOptions();
options.host = "localhost";
options.port = 8080;
options.reconnect = false;
client.connect(options);

Or change the default value in ofxLibwebsockets/Client.cpp from true to false

@robotconscience Maybe changing the default val for reconnect to false is a good idea for now until this context thing gets figured out?

[robotconscience]

@mattfelsen yeah that sounds like a good idea!

RE: that fixing @dboleslawski's error, see his above comment. Sounds like there's something weird going on under the hood with lws that makes it impossible :(

[mattfelsen]

Hmm, funky. The thing in the screenshot looks like a different error though – an unrecognized protocol? @dboleslawski I assume you're using this arduino/esp8266 websocket library, and your board is acting as the server? That lib defaults the protocol to "arduino" on both the server and client side...I wonder if setting the protocol to an empty string would make the lws client app stop complaining about connecting?

In any case, with reconnect on I'm able to reproduce the same error if I lower the interval to something like 300ms, and turning it off makes the error disappear so hopefully it's a temp workaround for now. Tiny PR with warning note coming your way!