Closed SystematicCZ closed 4 months ago
Hmmm, I haven't seen this one before. Do you know what conditions trigger it?
SIGPIPE: Broken pipe: write to pipe with no readers;
Is this meaningful to you @SystematicCZ? Are you doing anything with pipes? I'm 90% sure we aren't doing anything with pipes in frankenphp.
Are you using the latest version? We fixed a SIGPIPE-related issue in https://github.com/dunglas/frankenphp/pull/651
Also, could you show us the PHP code that triggers this error. The missing SA_ONSTACK
flag is likely in a non-default extension that needs to be patched (PHP and FrankenPHP use SA_ONSTACK
by default).
SIGPIPE Yeah, I was still on 1.1.0 on my dev machine, but on production we have 1.1.1 (I double checked now). I still have these errors in the logs on production
{"level":"error","ts":1711213787.9251857,"msg":"write error","error":"write tcp 172.19.0.3:80->213.109.164.248:36804: write: broken pipe"}
The The missing SA_ONSTACK
error occurred while Symfony debug bar was loading. I just loaded the homepage of our app where nothing interesting is happening and the debug bar showed "There was an error loading a debug bar"...
Also randomly I get this
{"level":"error","ts":1711207183.7783015,"msg":"PHP Fatal error: Cannot declare class ComposerAutoloaderInit3f08b7b0898acdf10cdff3718f827856, because the name is already in use in /www/vendor/composer/autoload_real.php on line 5","syslog_level":"err"}
zend_mm_heap corrupted
I tried to hunt down the specific script that causing this but it seems to occur on random URLs.
I will try to get a core dump if it will be helpful
The log with the write error is expected, it just mean that a network error occurred.
The heap corrupted error however, is concerning and unexpected.
This may be related to an extension too.
A core dump would indeed help a lot.
@SystematicCZ https://github.com/php-amqp/php-amqp/pull/550 should entirely fix the issue. Could you try this patch and confirm if it's the case or not? Thank you!
Will try today and let you know.
No more SA_ONSTACK errors, but I still got heap corrupted error. I cannot replicate it on my dev machine. I will get the core dump from prod but since we have managed servers it will take some time.
If possible, try to compile PHP and php-amqp (the bug is probably in this extension) with debug symbols.
@dunglas - I just got this today with frankenphp:1.2-php8.3.10-alpine
signal 13 received but handler not on signal stack
mp.gsignal stack [0xc00058e000 0xc000596000], mp.g0 stack [0x7fedeba20d00 0x7fedebaa0900], sp=0xc000a8b938
fatal error: non-Go code set up signal handler without SA_ONSTACK flag
The stack trace is huge, I am not sure what to paste from it.
L.E:
goroutine 15 gp=0xc0006028c0 m=nil [chan receive, 279 minutes]:
runtime.gopark(0xae1865?, 0x1b09160?, 0x1?, 0x0?, 0xc0000a9da8?)
/goroot/src/runtime/proc.go:402 +0xce fp=0xc0000a9d18 sp=0xc0000a9cf8 pc=0x44560e
runtime.chanrecv(0xc0003226c0, 0xc0000a9f70, 0x1)
/goroot/src/runtime/chan.go:583 +0x3bf fp=0xc0000a9d90 sp=0xc0000a9d18 pc=0x40e27f
runtime.chanrecv2(0xc0003226c0?, 0xc00048a780?)
/goroot/src/runtime/chan.go:447 +0x12 fp=0xc0000a9db8 sp=0xc0000a9d90 pc=0x40deb2
github.com/caddyserver/caddy/v2.trapSignalsPosix.func1()
/root/go/pkg/mod/github.com/caddyserver/caddy/v2@v2.8.4/sigtrap_posix.go:35 +0x105 fp=0xc0000a9fe0 sp=0xc0000a9db8 pc=0xb04a85
runtime.goexit({})
/goroot/src/runtime/asm_amd64.s:1695 +0x1 fp=0xc0000a9fe8 sp=0xc0000a9fe0 pc=0x47d981
created by github.com/caddyserver/caddy/v2.trapSignalsPosix in goroutine 1
/root/go/pkg/mod/github.com/caddyserver/caddy/v2@v2.8.4/sigtrap_posix.go:31 +0x1a
If you are using php-amqp extension, you must install specific commit from master because there was no release since January. Or there is similar bug in another extension
RUN set -eux; \
install-php-extensions php-amqp/php-amqp@a9cbd81ea401d4ba41b72381008b331f5516823c
@SystematicCZ - Thank you, I was sure I used latest version after I read the comments. But as you say, I see there is no release made to contain the fix yet, so your solution is what ended up working. Thank you again!
What happened?
Running Symfony app behind reverse proxy (caddy) in non-https mode results in crashes (both on dev and prod).
My Caddyfile
Build Type
Docker (Alpine)
Worker Mode
No
Operating System
macOs
CPU Architecture
Apple Silicon
PHP configuration
Relevant log output