[SOLVED] Unwanted SIGTRAP when adding breakpoints on Linux

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • [SOLVED] Unwanted SIGTRAP when adding breakpoints on Linux

    Setup: J-Link V6.72a on Ubuntu 18.04 for my STM32F302CC using J-Link Mini EDU.

    Configurations: Using CLion with "Embedded GDB Server": /usr/bin/JLinkGDBServer -select USB -device STM32F302CC -endian little -if SWD -speed 4000 -ir -LocalhostOnly -vd -strict

    When I try to add a new breakpoint in CLion, the debugger will immediately break at whatever line is being executed with a SIGTRAP (i.e. NOT where I set the breakpoint). Note that this is different than the SIGINT that I would receive for a normal breakpoint. I can continue the program execution manually afterwards but this is quite inconvenient.


    Suppose I am adding breakpoint 5 to main.c:627. This is what I observe (with some annotated comments):
    Program received signal SIGTRAP, Trace/breakpoint trap. # The SIGTRAP happens as soon as I set the breakpoint, and we pause at task.c:3376 because the program execution happens to be there
    0x08008dd8

    in prvCheckTasksWaitingTermination () at
    /home/thekenu/Consolidated-Firmware/boards/DIM/Middlewares/Third_Party/FreeRTOS/Source/tasks.c:3376
    3376 while( uxDeletedTasksWaitingCleanUp > ( UBaseType_t ) 0U )

    # Here I press "Continue", and we pause at main.c:627 where breakpoint 5 was set
    Breakpoint 5, StartTask1kHz (argument=0x0) at /home/thekenu/Consolidated-Firmware/boards/DIM/Src/main.c:627
    627 Io_CanTx_EnqueuePeriodicMsgs(

    The post was edited 4 times, last by thekenu ().

  • Hi,
    Thank you for your inquiry.
    Such an issue is not known to us.

    I assume you are using the same Hardware as in the other thread you created. Correct?
    Could you please also send us a J-Link log file of this session?

    Best regards,
    Fabian
    Please read the forum rules before posting: Forum Rules

    Keep in mind, this is not a support forum. Its main purpose is user to user interaction.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/


    Or you can contact us via e-mail.
  • Hi again Fabian, you're right that I am using the same hardware as the other thread. For completeness, I will copy over some of the information from that thread. Please note that I have created a **different** log file to highlight the SIGTRAP problem I mentioned in this thread.

    1) I am using custom hardware but I was able to reproduce it on a
    evaluation board. I switched to using a Nucleo Board (STM32F302R8).
    1.1) To keep the scope manageable. I will just use the Nucleo Board as a benchmark rather than my custom hardware.
    2) I've attached a log file. For your information, a rough description of what I did in CLion is:
    Step 1. Start the debugger no breakpoints.
    Step 2. Click on the "Pause" button in CLion. Turns out the program is stuck in HardFaultHandler.
    Step 3. Click on the "Reset" button in CLion, let the program run for a bit, and then click on the "Pause" button in CLion. Observe that we are no longer stuck in HardFaultHandler.
    Step 4. Click on the "Continue" button in CLion.
    Step 5. Set a breakpoint at main.c:112, observe a SIGTRAP occurs and we pause at main.c:97. Click on the "Continue" button in CLion.
    Step 6-9. Repeat step 5 with a new breakpoint each time on main.c:117-120. An unwanted SIGTRAP occurs every time.

    Since the project is empty and the infinite while loop is empty. The unwanted SIGTRAP always happens at the same place (PC = 0x8001608). I figured the PC would be helpful for you.

    while (1)
    8001608: e7fe b.n 8001608 <main+0x10>


    I've added .asm file to the repo too for you guys to analyze.

    3) Here is a bare minimum project I created with STM32CubeMX: github.com/thekenu/jlink_test (Please use the "Embedded GDB Server" configuration file in CLion 2020.1.1 to reproduce this bug).

    (By the way: The Github project is the same between the two threads I made!)
    Files
    • myLog

      (751.38 kB, downloaded 71 times, last: )

    The post was edited 2 times, last by thekenu ().

  • Hello all,

    I do not really see a problem on the GDBServer side here.
    a) There was some IMPORTANT information missing initially.
    The SIGTRAP only occurs when setting a breakpoint in CLion while the target CPU is running.
    This is a special case for GDB because by default GDB runs in stop mode.
    In this mode after a "continue" is issued, GDB becomes blocking and does not accept new commands like "R/W memory" or "Set/Clear BP".
    GDB keeps blocking until J-Link GDBServer respons to the continue command with a "target is halted again because of reason xyz".
    There is only one exception that GDB accepts while waiting for a response to a continue packet:
    An interrupt (Ctrl + C) which sends a 0x03 packet to GDBServer that is a "request to halt CPU"

    So this is where CLion adds its work-around to make set/clear BPs while running working:
    If you set a BP in CLion while the CPU is running, CLion does the following internally:
    • Issue a Ctrl + C to GDB
    • GDB now sends a 0x03 packet to GDBServer (sourceware.org/gdb/current/onl…nterrupts.html#Interrupts)
    • GDBServer halts the target CPU
    • GDBServer now sends the response to the previous "continue" packet ('c'): sourceware.org/gdb/current/onl…s.html#Stop-Reply-Packets
    • The response may either be 'S AA' or 'T AA n1:r1;n2:r2;...' (See link above)
      GDBServer always uses the 'T' variant because many GDBs do not handle the 'S' variant correctly.
      Further, the documentation says that if 'n' is a recognized stop reason, AA (the received signal) should be '05'.
      This is exactly what GDBServer sends
    • Now that GDB received the response to the 'c' packet, it becomes responsive again and accepts further commands
    • Now CLion issues a "SetBP" command to GDB
    • Now CLion issues a "continue" again
    For the user, the halt + setbp + go happens behind the scenes so that in the IDE you should not see that the CPU was halted implicitly by your "SetBP" for a short period of time.

    On the protocol level, the same packets are send to GDBServer, no matter if you hit "pause" in CLion or issue a "SetBP" while the CPU is running.
    In both cases, CLion issues a "halt" request to GDB which results in a 0x03 packet being send to GDBServer.
    So for GDBServer, both cases look identical and therefore in behaves the same in both cases.

    To me, it sounds like that there is a problem in CLion not correctly hiding the temporary halt of the CPU during the SetBP() handling.
    Or it does not properly auto-continue the CPU after setting the BP.

    If the CLion developers disagree, we are happy if you get us in touch with them and work on a solution.


    BR
    Alex Gruener (J-Link PM)