Segmentation fault built with zig cc $ARCH-linux-musl

[cattyhouse]

if the binary is built with zig cc ARCH-linux-musl, Segmentation fault in 2 cases

1. #20 (comment)

if change udp: 'udp' to udp: 'tcp', i know this mode only works with hev-socks5-server, it does not work with trojan-r socks5 listening. when sending a udp packet like dig @1.1.1.1 example.com (udp packet), hev-socks5-tproxy just exit with Segmentation fault, i know it will fail, but that could be handled better with some error message instead of exit with seg fault. (side note, in this case trojan-r log shows: socks: unsupported command 0x5), just some thoughts, not a big issue if one knows how to configure the udp: parameter.

2. #20 (comment)

i found another hev-socks5-tproxy Segmentation fault when upstream socks5 server stopped/killed/quit/no longer listening. can you reproduce this behavior on your side?

not effected when using zig cc ARCH-linux-gnu, tested zig version 0.11,0.12-dev

build arg

# STRIP=true disables strip in Makefile, as we have zig cc -s to strip
make clean ;
make \
CC='zig cc -flto -O3 -s -static -target aarch64-linux-musl' \
AR='zig ar' \
RANLIB='zig ranlib' \
STRIP=true \
-j

EDIT: issue fix by setting task-stack-size in config.yml equal or larger than 8193. Or even larger, e.g. : 16384 is preferred

[heiher]

I can't reproduce it here. :( I'm not sure if it's a specific compiler or C library that's causing the coroutine task's stack to overflow, but it's easily confirmed by increasing the stack space.

misc:
   task-stack-size: 65536

[cattyhouse]

interesting, setting that equal or larger than 9000, the seg fault will not appear.

[cattyhouse]

to be precise, larger or equal than 8193 will not cause seg fault in above 2 cases.

[heiher]

Thanks for your feedback.

The stack size is page aligned, it's allocated by mmap. We can increase the default value to 16k (or higher) without any scruples, and it will not waste physical memory if the actual usage is low.

[cattyhouse]

make a note in the example yml config would be sufficient if increasing predefined stack size might effect other $ARCH, which i don't have hardware to test.

[heiher]

Fixed: c8f7744