Closed dset0x closed 3 years ago
Note that I was forced to comment this out for the build to complete (might as well be the source of my problems)
diff --git a/src/lib/lwan-websocket.c b/src/lib/lwan-websocket.c
index a484b1f..3a6a4c1 100644
--- a/src/lib/lwan-websocket.c
+++ b/src/lib/lwan-websocket.c
@@ -121,7 +121,7 @@ static size_t get_frame_length(struct lwan_request *request, uint16_t header)
{
size_t len;
- static_assert(sizeof(size_t) == sizeof(uint64_t), "size_t has a sane size");
+ /* static_assert(sizeof(size_t) == sizeof(uint64_t), "size_t has a sane size"); */
switch (header & 0x7f) {
case 0x7e:
I have also commented out lua, brotli and zstd from CMakeLists.txt, because the build host has these, but the target platform does not.
I rarely test Lwan on ARM, let alone with uClibc. Coroutines in C are but a hack, so stuff like this is bound to happen on untested platform combinations.
The getcontext()
function is implemented in assembly, so you'd have to step through it at an instruction level to see what's actually causing the segmentation fault. Set up a breakpoint there before main()
starts and go from there. Maybe the answer is just to provide a 1st-class implementation of coroutines for ARM, but I'm not familiar enough with the platform, or have the need right now, to implement it properly; there are some coroutine libraries out there (I've starred some of them here on GitHub) with ARM support, which might help figure out what's needed.
BTW, it's unlikely that the thing you've commented out is the source of the problem, unless you're trying to receive WebSockets frames that are larger than 64KB.
Thanks for taking a look, @lpereira. I understand if support for this is not a priority. I am not sure if I will be able to eventually make sense of this. My gdb fails to create a record due to lack of support for some instruction, but for reference, I'm including some output from stepping through it.
```
gdb lwan
GNU gdb (GDB) 7.6
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
Interesting. It's trying to store the SIMD registers onto address 0. Not sure if a bug in uClibc, or what's happening here. What version of uClibc are you using? The uClibc-ng, I presume, since the original one has not been maintained in a few years?
The funny thing is that I added 32-bit x86 support for Lwan's coroutines (rather than relying on the deprecated ucontext.h
, which wasn't available in the original uClibc) because I wanted to use it on a x86 board with an OS built with this C library. Will probably have to add 1st-class support for ARM processors. This will take a while as I'm not working on any project in my free time for a while, but I'll keep this issue updated.
One of the things we could try here is to use libucontext -- and use it instead of the ucontext provided by the C library. It should be possible to do this with minimal changes to the build system. (I don't have an ARM machine I can play with readily here. My RPis are being used right now and I can't disturb them.)
I've tentatively pushed a change to CMakeLists.txt so that it'll look for libucontext
when building on ARM. Could you please try this out after installing that library?
Hey - appreciate you looking for a fix already!
Note I'm building with buildroot now to save myself from figuring out how to get it to detect libucontext. Seems to be loading the new library,
...
-- armv7l processor detected, looking for libucontext
-- libucontext found, using it for context switching routines
...
Note that I couldn't get gdb to load the sources this time, so the breakpoint is on getcontext
. I'm not sure if that was the right thing to do, or if the right getcontext
is actually being used.
```
Breakpoint 1, 0x76e747e0 in getcontext () from /lib//libc.so.0
(gdb) display/i $pc
1: x/i $pc
=> 0x76e747e0
From the looks of it, the getcontext()
being used is from the C library. Will see if I can find a spare SD card here and remove the dust from my RPi and see what I can do. It's time for proper ARM support :)
Hi -- it took a long while but I've finally fixed the libucontext support yesterday. Tested working on a Raspberry Pi (AARCH64) running Raspbian. You have to build the library with meson rather than make, though; the Makefile seems broken somehow.
Better yet -- now, if you build Lwan on non-x86 targets, it should download and build libucontext for you (they merged a patch I sent fixing build with Makefiles on armv7l today).
Thanks so much for fixing this. Unfortunately I no longer have access to the hardware or build environment this was targeting. (I had to continue that project with a different server)
Feel free to close this issue!
Hello,
I build lwan-latest using ImportExecutables.cmake from a native build, using a buildroot uClibc (arm-buildroot-linux-uclibcgnueabihf).
I then run lwan (under gdb) and make a request to it to trigger the problem.
I am not quite sure how to debug this any further. Please let me know if I can help with more output.