Segmentation fault
talaikis opened this issue · 7 comments
Trying again, server (for Django 1.11) starting fine, but segmentation fault with the first request. Tried both with .whl and own.
syslog:
Apr 12 17:41:47 ip-172-31-16-6 kernel: [15842.063880] python3.6[10399]: segfault at 10 ip 00007f90485eeb40 sp 00000000024033e0 error 4 in libpython3.6m.so.1.0[7f9048458000+26e000]
Apr 12 17:44:11 ip-172-31-16-6 dhclient[881]: DHCPREQUEST of 172.31.16.6 on eth0 to 172.31.16.1 port 67 (xid=0xe9c8c1a)
Apr 12 17:44:11 ip-172-31-16-6 dhclient[881]: DHCPACK of 172.31.16.6 from 172.31.16.1
Apr 12 17:44:11 ip-172-31-16-6 dhclient[881]: bound to 172.31.16.6 -- renewal in 1458 seconds.
Apr 12 17:56:37 ip-172-31-16-6 kernel: [16731.684545] python3.6[11254]: segfault at 11 ip 00007f818d547b40 sp 0000000001607c70 error 4 in libpython3.6m.so.1.0[7f818d3b1000+26e000]
Please try the recent version. If the problem persists I will need full info about your setup to try to re-produce the problem.
I tried a simple Django 1.11/Python 3.6 project with a local SQLite database on Windows and Ubuntu Xenial, and everything works fine even with a test by wrk (10 threads, 10 connections for 30s).
Hm... then seems it's somewhere project related, despite it runs fine on Django own wsgi, but how to debug it then if it's not persistent?
Does your project use third-party Python packages that include binary components (like Pillow and such)? Because WsgiBoost itself does not use potentially unsafe types/containers, but interoperability between C++ and Python is a tricky thing.
Anyway, as I said, I need full info about your setup, if it is possible.
BTW, Django uses Python's built-in WSGIServer server for test run.
Yes, it uses Pillow and much more. It's not so easy to describe the setup as it includes many components and to track down which one causes it is too hard. What I can say, it works with any other server, for example aiohttp, uwsgi. I probably would try it from scratch then to track exact issue when would have some time.
It would be bad if third-party binary modules turned out to be show-stoppers. My C++ skills are limited, so finding a root cause will be difficult.
I can only recommend to try the latest version, and also try to set a single thread to check, if some race condition is an issue.
I would also ask you to test connection with curl -v to see if server actually sends a response before crashing. I was able to catch similar issue with C-based ujson package that was used to emulate a REST response.
Unfortunately, WsgiBoost does indeed have problems with third-party Python-C binary modules, both on Windows and Linux. Since finding the root cause is beyond my abilities (at least for now), I'm putting the project on hold. Please read the notice in the Readme. Thanks for trying it anyway.