ESP32 Forum

I force esp32 to get into a crash and it indeed stuck on gdb stub as expected.
Of course, I have changed Panic handler behaviour to Invoke GDBStub before building this app.
Then I exit the screen terminal and release the serial port not to be occupied by the terminal.

Next, I execute the following command.
It's stuck and the last message just shows reading symbols done, there is no gdb session.
Also attached my xtensa-esp32-elf-gdb configuration for your reference, I didn't do any change.
I am almost sure it's stuck on connecting to remote target because when I try to target remote to nonexistent port ( such as /dev/tty.SLAB_USBtoUART1 ) or the port occupied by screen terminal, it will show "/dev/tty.SLAB_USBtoUART1: No such file or directory." or "/dev/tty.SLAB_USBtoUART: Resource busy", and then it will still go to gdb session.

But in this case, just stuck and no gdb session.

Thanks

I had the same problem on OS X. While I don't know what's causing it, I have worked around it using a tcp_serial_redirect.py script from pyserial examples.

Thanks, tcp_serial_redirect is working good.
However, I also found that there is an alternative to use xtensa-esp32-elf-gdb working on a serial port without redirecting it to tcp, that is, using /dev/cu* instead of /dev/tty*.
In MAC, /dev/tty* are called "callin devices", are used for incoming traffic, any process trying to open them will block within open() call until a data-carrier-detect signal is triggered from hardware.
But /dev/cu* doesn't have such restriction.

So I change the command as below, it also works good~