Http Socket Crashes WebServer

  1. 2 years ago

    Daniel W

    18 Jul 2017 Australia
    Edited 2 years ago

    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 2 years ago

    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. last year

    Daniel W

    14 Feb 2018 Australia

    I can confirm that glibc-2.17 is not supported.

  8. 7 months ago
    Edited 7 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. Are we talking about a crash? Or is it an exception?

  10. 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. 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. Edited 7 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. Will do. (at some point). I would be interested to know if other platforms have this issue.

  14. @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!