Using Fibers causes epic crash

[withinboredom]

Minimal code to reproduce:

<?php

do {
    $running = false;
    //$running = frankenphp_handle_request(function (): void {
        $fiber = new Fiber(function() {
            echo "Starting Fiber\n";
        });
        $fiber->start();
    //});
} while ($running);

With some slight modifications, it can also be reproduced in worker mode.

[withinboredom]

@dunglas the following Docker file (props @cdaguerre in #374) appears to "fix" fibers. At least for this reproducer with manual testing. It needs more testing:

FROM dunglas/frankenphp:latest-builder-php8.3-alpine AS builder

COPY --from=caddy:builder-alpine /usr/bin/xcaddy /usr/bin/xcaddy

ENV CGO_ENABLED=1 XCADDY_SETCAP=1 CGO_CXXFLAGS=-fPIE CGO_CFLAGS=-fPIE CGO_LDFLAGS=-pie XCADDY_GO_BUILD_FLAGS='-buildmode=pie -ldflags="-w -s" -trimpath'
RUN xcaddy build \
    --output /usr/local/bin/frankenphp \
    --with github.com/dunglas/frankenphp=./ \
    --with github.com/dunglas/frankenphp/caddy=./caddy/ \
    --with github.com/dunglas/mercure/caddy \
    --with github.com/dunglas/vulcain/caddy

🥳 🤞 🤞 still testing...

[dunglas]

Great news! Don't hesitate to open a PR with this changes, so we can see if this fix the issue for all architectures.

[withinboredom]

I'll do some proper testing by Monday (by updating the fiber branch), but I haven't seen a crash yet via manual testing.

[piotrekkr]

@withinboredom I had issues with fibers so I could also test this on my Cloud Run service but not really sure where can I get docker image to use with this fix.

[withinboredom]

It doesn't fix it, per se, more-or-less just reduces the probability of a crash.

Edit to add: the best way to prevent a crash is to just not output anything at all inside a fiber.

[erikfrerejean]

I've just encountered this issue and using the workaround from @withinboredom did resolve the exception. In this project the culprit seem to be the monolog logger as that is the only place fibers are being used.

[withinboredom]

I started working on a cgo library several weeks ago to allow output from c to go without calling go. It's still a wip: https://github.com/withinboredom/cgoc

There's a segfault once the number of concurrent requests gets high (due to usage of some C synchronization primitives from go), and a memory leak, but the it's pretty fast by itself (~8gbs on my machine).

I hope to have it working sometime in the next few months as a potential solution.

[dunglas]

@withinboredom IMHO the best option would be to fix the issue directly in Go!

[withinboredom]

@dunglas I highly doubt it will ever be fixable, for very valid reasons. The reason it is failing boils down to the following:

1. C creates a new thread
2. C calls go_handle_request (ncgo = 1)
3. Go calls frankenphp_execute_script (reenter C)
4. PHP creates a fiber
5. C calls Go (go_ub_write for example) (ncgo = 2)
6. crash as designed

According to the CL (https://go-review.googlesource.com/c/go/+/530480) this means changing the stack for an ncgo > 1 will never be possible -- for very valid safety reasons. This was a huge part of my approach in taking over Go threads (ncgo <= 1 always).

If we can fix the ncgo issue, then we are free to muck around with the stack as much as we want.

[withinboredom]

One way to fix it might be to have go_handle_request return a pointer that we can continue with (making ncgo = 0), then continuing in C to frankenphp_execute_script, so if a fiber is created, and we call things like go_ub_write, ncgo == 1 and it will just reset the stack bounds just fine (in theory).

[dunglas]

According to golang/go#62130 (comment), this seems fixable directly in Go for our case.