Seemingly randomly, sending a request with a async xojo socket crashes the entire web app in debug mode. When I check the logs I get the following error.
Unexpected error 9 on netlink descriptor 8
The webapp crashes from about 1 in 20 requests. I have checked that libsoup 2.4 is installed.
I haven’t observed this in a built application yet, but it does frighten me! Does anyone have any ideas?
Note: I am sending Json and image data over the socket. I am also running many timers in the app. Could a timer cause a conflict?
I did a search and found:
- getaddrinfo now detects certain invalid responses on an internal netlink
socket. If such responses are received, an affected process will
terminate with an error message of "Unexpected error on netlink
descriptor " or "Unexpected netlink response of size on
descriptor ". The most likely cause for these errors is a
multi-threaded application which erroneously closes and reuses the netlink
file descriptor while it is used by getaddrinfo.
What OS are you debugging in?
Thanks Phillip, I couldn’t find this with all my googling.
I’m am debugging on Ubuntu 16.04.
At least we why the app is crashing… although, I don’t use a C library that I know of. Perhaps it’s part of Xojo’s innards.
Yes Xojo does use glibc internally.
Ubuntu 16.04 seems to use glibc 2.23
My production system uses glibc 2.17 so I will test it thoroughly and see if the problem persists.
The Xojo website states that glibc-2.14 (64-bit) is required. I’m sure there are others who run ubuntu 16.04 on a production system. Does Xojo support newer versions of the required dependencies?
I can confirm that glibc-2.17 is not supported.
Unfortunately this issue has made the Xojo.Net.HTTPSocket undeployable on CentOS.
Xojo claims centos 7 is supported, but it contains glibc-17.222 which causes the entire webapp to crash if a error code (such as 400) is returned to from a post. unhandled exception in the socket occurs.
Downgrading glibc is defiantly not an option for Centos 7
I tried the latest version of ubuntu 18.04 which runs a new version of glibc (2.27). This did not fix the issue. At least the issue has been replicated on Ubuntu and Centos now.
Any ideas out there?
Are we talking about a crash? Or is it an exception?
Yep, A crash. It can be repeated reliably.
6 Segmentation fault (core dumped) /opt/SomeApp/SomeApp --Port=8090
config_SomeApp_1 exited with code 139
So i found it wasn’t simple error code that was causing the crash, it was a malformed URL. I forgot the two forward slashes after “http:”
By removing the forward slashes. the follwoing code will crash the entire web app.
I still believe the issue is related to the OP. It would seem any unhandled exception on the Xojo.Net.HTTPSocket causes the app to crash.
That may be, but an error 400 would not raise an exception.
Excellent. File a bug report with a repeatable sample so we can fix it!
Will do. (at some point). I would be interested to know if other platforms have this issue.
Yep, that’s right. I got error codes back no worries now. The crash was due to the malformed url I was testing with.