Strange behavior of breakpoints on PHP 8.1.6, Xdebug 3.2.0 and Swoole 5.0.2

[MadridianFox]

Please answer these questions before submitting your issue.

1. What did you do? If possible, provide a simple script for reproducing the error.

Trying to use xdebug for step debugging.
Steps to reproduce:

• install swoole 5.0.2 and xdebug 3.2.0 on top of php:8.1.6-fpm-alpine3.16
• create laravel project with laravel octane
• configure xdebug and phpstorm for debugging
• try to use step debugging

2. What did you expect to see?

I expect it to work like fpm - I can put a breakpoint anywhere at any time, refresh the page and the app will stop.

3. What did you see instead?

When i make a breakpoint in controller and open a page in browser, it randomly stops or not.
Restart of the application randomly changes the situation - breakpoint may become work or broken.

4. What version of Swoole are you using (show your php --ri swoole)?

Swoole 5.0.2
Installed via compilation commit 6809ae4

Swoole => enabled
Author => Swoole Team <[email protected]>
Version => 5.0.2
Built => Feb  6 2023 14:50:41
coroutine => enabled with boost asm context
epoll => enabled
eventfd => enabled
signalfd => enabled
spinlock => enabled
rwlock => enabled
http2 => enabled
json => enabled
zlib => 1.2.12
brotli => E16777225/D16777225
mutex_timedlock => enabled
pthread_barrier => enabled
async_redis => enabled

Directive => Local Value => Master Value
swoole.enable_coroutine => Off => Off
swoole.enable_library => On => On
swoole.enable_preemptive_scheduler => Off => Off
swoole.display_errors => On => On
swoole.use_shortname => On => On
swoole.unixsock_buffer_size => 8388608 => 8388608

5. What is your machine environment used (show your uname -a & php -v & gcc -v) ?

PHP docker image: php:8.1.6-fpm-alpine3.16
Kernel: 5.4.0-137-generic #154-Ubuntu SMP Thu Jan 5 17:03:22 UTC 2023 x86_64 Linux

Dockerfile

FROM php:8.1.6-fpm-alpine3.16

ARG LIBRDKAFKA_VERSION=1.6.1
ARG PHP_RDKAFKA_VERSION=5.0.2

RUN apk add --virtual .build-deps --no-cache --update $PHPIZE_DEPS \
        zlib-dev freetype-dev libjpeg-turbo-dev libwebp-dev libpng-dev libzip-dev postgresql-dev librdkafka-dev \
        bash git && \
    apk add --repository http://dl-cdn.alpinelinux.org/alpine/edge/community/ --allow-untrusted \
        gnu-libiconv freetype libjpeg-turbo libwebp libpng libzip libpq librdkafka && \
    pecl install rdkafka-$PHP_RDKAFKA_VERSION apcu redis && \
    \
    git clone --branch=master --depth=1 https://github.com/swoole/swoole-src.git && \
    cd swoole-src && \
    phpize && \
    ./configure && \
    make && make install &&\
    cd .. && rm -rf swoole-src && \
    \
    docker-php-ext-configure gd \
        --with-freetype=/usr/include/ \
        --with-webp=/usr/include/ \
        --with-jpeg=/usr/include/ && \
    docker-php-ext-install pdo_pgsql gd zip opcache pcntl && \
    docker-php-ext-enable apcu pdo_pgsql redis rdkafka swoole && \
    apk del -f .build-deps && \
    pecl clear cache

[Cluster2a]

@MadridianFox same here - after changing a breakpoint, I need to restart the container.
I started working with xdebug_break() for now.

[oprypkhantc]

I don't think this is related to Swoole; it seems to be the issue of Xdebug itself. When you run a plain PHP script and try to add a breakpoint while it's running, it doesn't work either.

I've reported it on XDebug side to see if I'm correct: https://bugs.xdebug.org/view.php?id=2161

[Rastusik]

AFAIK you need to set breakpoints before running the script or during a break on another breakpoint. This works well for my setup which seems to be the same as yours

[huanghantao]

When you add a breakpoint in an IDE, it sends a breakpoint request to xdebug. The added breakpoint is only effective if xdebug can process the breakpoint request.
The reason why you can continue adding breakpoints while the program is stopped at a breakpoint is that xdebug blocks the program's continued execution, takes control of your application, and can receive instructions from the IDE, such as adding another breakpoint. However, when the program has completed its execution, it is no longer under the control of xdebug and may be blocked by event-driven processes, making it unable to receive breakpoint requests from the IDE.
If xdebug is a multi-threaded model, it is possible to add breakpoints after the program has started running