Debugging with Posix Simulator - Cygwin - SIGTRAP

Hi, i’ve a problem when debugging a project that uses FreeRTOS Posix simulator on Windows/cygwin.

  • IDE: eclipse 2019 CDT
  • FreeRTOS Kernel: V10.4.3
  • Debugger: GDB
  • Cygwin GCC version: 10.2.0
  • GNU gdb: (Cygwin 9.2-1) 9.2

The problem is that when i single step code the signal SIGTRAP will often stop the execution:

Thread 6 "LibTemplate" received signal SIGTRAP, Trace/breakpoint trap.
0x611015cc in sigdelayed () from /usr/bin/cygwin1.dll

Is there any way to avoid execution stopping while I’m stepping?

I’ve masked the signals SIGUSR1, and SIGALRM as explained in:

I’ve tried also disabling SIGTRAP in the same way but this lead to a segmentation fault.

Thank you very much!

SIGTRAP, is triggered when you set a breakpoint/watchpoint in your code.
One way of hitting it, is if you are stepping over a function tree with a breakpoint watchpoint somewhere inside of it.
The location of the trace shows that it is the function sigdelayed inside cygwin1.dll, not sure why cygwin.dll is reporting a break/watch point …
Could you please do a backtrace and show us the content?

Also try to set the SIGTRAP signal differently as by default behavior is to kill the process if not debugged.

$ handle SIGTRAP nostop ignore nopass noprint

The main difference here is the “nopass” so gdb does not pass the signal to the inferior and kill the process.

How often is that ?

Thank you very much for your reply!

Here is an example of the backtrace of the thread that hit SIGTRAP, i don’t have sigdelayed() calls on thread code.

#0  0x611015cc in sigdelayed () from /usr/bin/cygwin1.dll
#1  0x0040151f in AppData_WrValue (DataID=0, Value=2147483647) at ../Sources/AppData/AppData.c:147
#2  0x00401a8c in APDTest_Handle () at ../Sources/AppData/AppDataHandle.c:79
#3  0x00401b50 in AppDataHandle_Task () at ../Sources/AppData/AppDataHandle.c:116
#4  0x00401df2 in PrjC_Run () at ../Sources/PrjC.c:68
#5  0x004028ca in SysPrjC_Process () at C:/Progetti/Software/LibTemplate/Core/Sys/SysPrjC.c:91
#6  0x00405133 in prvWaitForStart (pvParams=0x41f130 <ucHeap+656>) at ../Local/Core/External/RTOS/FreeRTOS/portable/ThirdParty/GCC/Posix/port.c:435
#7  0x61130168 in pthread::thread_init_wrapper(void*) () from /usr/bin/cygwin1.dll

When i have setup the SIGTRAP as described i can do some debug steps, but at a some point the debug halts and gdb output is:

handle SIGTRAP nostop ignore nopass noprint
SIGTRAP is used by the debugger.
Are you sure you want to change it? (y or n) [answered Y; input not from terminal]
Signal        Stop	Print	Pass to program	Description
SIGTRAP       No	No	No		Trace/breakpoint trap
[New Thread 18524.0x24a0]
[New Thread 18524.0x4f5c]
/work/gdb-cygport/gdb-9.2-1.i686/src/gdb-9.2/gdb/infrun.c:5292: internal-error: int finish_step_over(execution_control_state*): Assertion `ecs->event_thread->control.trap_expected' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) [answered Y; input not from terminal]

This is a bug, please report it.  For instructions, see:

It happens only when stepping some instructions, how many depends from execution time i think, but it happens often (10/12 debug steps) on my project.
If i set a new breakpoint on the next instruction and i let the target run (no stepping), the problem not happens, but this is not praticable in all situations…

Anytime :slight_smile: … thanks for posting

Could it be when you hit a breakpoint you get that error ?
Are you on the latest stable versions of the stack you are using (cygwin, gdb… )
which version of gdb are you using? in their change logs for GDB 5.3 it says

The previous single-step mechanism could cause unpredictable problems,
including the random appearance of SIGSEGV or SIGTRAP signals. The use
of a software single-step mechanism prevents this.

We are seeing the same issue and have for some time. We typically run in Ubuntu under WSL1, so no cygwin involved but not a full linux kernel either.

Sometimes we hit SIGSEGV and sometimes SIGILL. In all cases it’s clear that the issue is not with our code itself.

The workaround of using a breakpoint or run-to-cursor works most of the time but not always. The error still occurs but less frequently.

One thing that alleviates the problem is reducing the configTICK_RATE_HZ. It seems that the issue happens more when running at full speed, eg. 1ms tick rate.


handle SIGUSR1 nostop noignore noprint
handle SIGPIPE nostop noignore noprint
handle SIGTRAP noprint ignore

Have tried with gdb 8.3 and 10.2, same behaviour.