Http Socket Crashes WebServer

  1. last year

    Daniel W

    18 Jul 2017 Australia
    Edited last year

    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
    Process Completed.
    App Ended

    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?

  2. Phillip Z

    18 Jul 2017 Pre-Release Testers, Xojo Pro Florence, SC

    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 <number> on netlink
    descriptor <number>" or "Unexpected netlink response of size <number> on
    descriptor <number>". 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.

    https://lists.gnu.org/archive/html/info-gnu/2016-02/msg00009.html

    -----

    What OS are you debugging in?

  3. Daniel W

    18 Jul 2017 Australia

    Thanks Phillip, I couldn't find this with all my googling.

    I'm am debugging on Ubuntu 16.04.

  4. Daniel W

    18 Jul 2017 Australia
    Edited last year

    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.

  5. Phillip Z

    18 Jul 2017 Pre-Release Testers, Xojo Pro Florence, SC

    Yes Xojo does use glibc internally.

  6. Daniel W

    18 Jul 2017 Australia

    Ubuntu 16.04 seems to use glibc 2.23
    https://launchpad.net/ubuntu/xenial/+source/glibc

    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?

  7. 10 months ago

    Daniel W

    14 Feb 2018 Australia

    I can confirm that glibc-2.17 is not supported.

  8. 2 months ago

    Daniel W

    Oct 9 Australia
    Edited 2 months ago

    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?

  9. Greg O

    Oct 9 Xojo Inc

    Are we talking about a crash? Or is it an exception?

  10. Daniel W

    Oct 9 Australia

    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
  11. Daniel W

    Oct 9 Australia

    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.

    TestHttpSocket.SetRequestContent(mbJson,txtMimeType)
     TestHttpSocket.Send("POST","http:127.0.0.1")

    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.

  12. Greg O

    Oct 9 Xojo Inc
    Edited 2 months ago

    @Daniel W 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.

    @Daniel W Yep, A crash. It can be repeated reliably.

    Excellent. File a bug report with a repeatable sample so we can fix it!

  13. Daniel W

    Oct 9 Australia

    Will do. (at some point). I would be interested to know if other platforms have this issue.

  14. Daniel W

    Oct 9 Australia

    @Greg OLone That may be, but an error 400 would not raise an exception.

    Yep, that's right. I got error codes back no worries now. The crash was due to the malformed url I was testing with.

or Sign Up to reply!