Hi,
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.
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:
<http://www.gnu.org/software/gdb/bugs/>.
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…
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.