[Bug breakpoints/26019] New: FreeRTOS task breakpoint causes core dump

[Bug breakpoints/26019] New: FreeRTOS task breakpoint causes core dump

[jeff at jkent dot net]

https://sourceware.org/bugzilla/show_bug.cgi?id=26019

            Bug ID: 26019
           Summary: FreeRTOS task breakpoint causes core dump
           Product: gdb
           Version: 9.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: breakpoints
          Assignee: unassigned at sourceware dot org
          Reporter: jeff at jkent dot net
  Target Milestone: ---

Created attachment 12559
  --> https://sourceware.org/bugzilla/attachment.cgi?id=12559&action=edit
Core dump from GDB 9.1

While debugging FreeRTOS on an ARM926EJ-S platform. I ran across a repeatable
GDB crash.  It happens with two different toolchains:

GNU gdb (GNU Tools for Arm Embedded Processors 9-2019-q4-major)
8.3.0.20190709-git
GNU gdb (crosstool-NG 1.24.0.105_5659366) 9.1

I am using Visual Studio Code as a frontend for GDB.  I am also using
JLinkGDBServer.  To rule out that it is a GDB server issue, I also tried using
OpenOCD.  The crash still occurred.

To reproducing the problem is an issue, because it requires specific hardware. 
If needed I can provide GDB server and target reset access by appointment. The
source of the project can be found at
https://github.com/jkent/pollux-baremetal/tree/gdb-bug .

  I think the next task would be to build GDB with debug symbols so the core
dump can provide a useful backtrace.  I do not know how to do this -- is there
a ./Configure option that can be passed to enable debugging?  This would be the
easiest route, to build a new toolchain with crosstool-ng.  Attached is the
core dump.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug breakpoints/26019] FreeRTOS task breakpoint causes core dump

[jeff at jkent dot net]

https://sourceware.org/bugzilla/show_bug.cgi?id=26019

--- Comment #1 from Jeff Kent <jeff at jkent dot net> ---
I should add, the breakpoint crash happens in examples/freertos-demo/main.c,
within the task_b function on line 61:

vTaskDelay(500 / portTICK_PERIOD_MS);

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug breakpoints/26019] FreeRTOS task breakpoint causes core dump

[keiths at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=26019

Keith Seitz <keiths at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |keiths at redhat dot com

--- Comment #2 from Keith Seitz <keiths at redhat dot com> ---
(In reply to Jeff Kent from comment #0)
> Created attachment 12559 [details]
> Core dump from GDB 9.1
> 
> To reproducing the problem is an issue, because it requires specific
> hardware.  If needed I can provide GDB server and target reset access by
> appointment. The source of the project can be found at
> https://github.com/jkent/pollux-baremetal/tree/gdb-bug .

That is going to slow things down a bit, yes.

Is it a crash/abort or an assertion failure?

Can you copy/paste your gdb session here demonstrating the problem? That might
provide some insight into what's going on.

>   I think the next task would be to build GDB with debug symbols so the core
> dump can provide a useful backtrace.  I do not know how to do this -- is
> there a ./Configure option that can be passed to enable debugging?  This
> would be the easiest route, to build a new toolchain with crosstool-ng. 
> Attached is the core dump.

Here's my standard debug build configure line. [Note this will enable
all target configurations.] You might change --prefix to point at a
distinct installation directory, but you do not normally need to install gdb to
use it. I run from the objdir all the time.

$ flags="-g3 -O0" CFLAGS="$flags" CXXFLAGS="$flags" /path/to/configure
--disable-binutils --disable-elfcpp --disable-gas --disable-gold
--disable-gprof --disable-ld --enable-unit-tests --with-system-readline
--with-separate-debug-dir=/usr/lib/debug --enable-targets=all --with-lzma
--prefix=/usr --with-separate-debug-dir=/usr/lib/debug

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug breakpoints/26019] FreeRTOS task breakpoint causes core dump

[jeff at jkent dot net]

https://sourceware.org/bugzilla/show_bug.cgi?id=26019

--- Comment #3 from Jeff Kent <jeff at jkent dot net> ---
Created attachment 12560
  --> https://sourceware.org/bugzilla/attachment.cgi?id=12560&action=edit
Debug log from cortex-debug visual studio code extension

It is an assertion failure.  I'll try reproducing this with the gdb console.

/home/jkent/tmp/arm-none-eabi/.build/arm-none-eabi/src/gdb/gdb/frame.c:587:
internal-error: frame_id get_frame_id(frame_info*): Assertion `stashed' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug breakpoints/26019] FreeRTOS task breakpoint causes core dump

[jeff at jkent dot net]

https://sourceware.org/bugzilla/show_bug.cgi?id=26019

--- Comment #4 from Jeff Kent <jeff at jkent dot net> ---
I was able to repro this bug with the following gdb session.  I'm using 8.3.0
because I accidentally wiped out my toolchain with GDB 9.1.  Woops.  It's
currently rebuilding.

GNU gdb (GNU Tools for Arm Embedded Processors 9-2019-q4-major)
8.3.0.20190709-git
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "--host=x86_64-linux-gnu --target=arm-none-eabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word".
(gdb) file examples/freertos-demo/build/freertos-demo.elf
Reading symbols from examples/freertos-demo/build/freertos-demo.elf...
(gdb) target remote localhost:2331
Remote debugging using localhost:2331
_vect_irq () at ../../baremetal/entry.S:41
41              ldr pc, [pc, #24]
(gdb) monitor halt
(gdb) monitor reset
Resetting target
(gdb) load
Loading section .entry, size 0xa4 lma 0x0
Loading section .entry_thumb, size 0x24 lma 0xa4
Loading section .text, size 0x3aa8 lma 0xc8
Loading section .rodata, size 0x58 lma 0x3b70
Loading section .data, size 0x10 lma 0x3bc8
Start address 0x0, load size 15320
Transfer rate: 56 KB/sec, 3064 bytes/write.
(gdb) monitor reset
Resetting target
(gdb) break examples/freertos-demo/main.c:61
Breakpoint 1 at 0x3b64: file main.c, line 61.
(gdb) continue
Continuing.

Breakpoint 1, task_b (
/mnt/workspace/workspace/GCC-9-pipeline/jenkins-GCC-9-pipeline-100_20191030_1572397542/src/gdb/gdb/frame.c:558:
internal-error: frame_id get_frame_id(frame_info*): Assertion `stashed' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) y

This is a bug, please report it.  For instructions, see:
<http://www.gnu.org/software/gdb/bugs/>.

/mnt/workspace/workspace/GCC-9-pipeline/jenkins-GCC-9-pipeline-100_20191030_1572397542/src/gdb/gdb/frame.c:558:
internal-error: frame_id get_frame_id(frame_info*): Assertion `stashed' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Create a core file of GDB? (y or n) y
Aborted (core dumped)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug breakpoints/26019] FreeRTOS task breakpoint causes core dump

[simark at simark dot ca]

https://sourceware.org/bugzilla/show_bug.cgi?id=26019

Simon Marchi <simark at simark dot ca> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |simark at simark dot ca

--- Comment #5 from Simon Marchi <simark at simark dot ca> ---
Is there a chance you could reproduce on Qemu?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug breakpoints/26019] FreeRTOS task breakpoint causes core dump

[jeff at jkent dot net]

https://sourceware.org/bugzilla/show_bug.cgi?id=26019

--- Comment #6 from Jeff Kent <jeff at jkent dot net> ---
(In reply to Simon Marchi from comment #5)
> Is there a chance you could reproduce on Qemu?

I don't think so :/ The POLLUX LF1000/VR3520F is obscure... it does share some
similarities to the Samsung S3C2451. I could try porting to the S3C2451
(FriendlyARM mini2451) since it shares a very similar interrupt controller.
Unfortunately it doesn't seem to be a machine definition for that platform
either.

What I'm trying to debug is context switching in FreeRTOS, within the timer
interrupt.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug breakpoints/26019] FreeRTOS task breakpoint causes core dump

[jeff at jkent dot net]

https://sourceware.org/bugzilla/show_bug.cgi?id=26019

--- Comment #7 from Jeff Kent <jeff at jkent dot net> ---
Created attachment 12561
  --> https://sourceware.org/bugzilla/attachment.cgi?id=12561&action=edit
Backtrace of arm-none-eabi-gdb v9.1

Ahh, I was having problems with crosstool-ng stripping symbols.  Now I got a
good backtrace.

Interestingly, if I re-attach to the target and the target is in the same state
as the breakpoint, it also crashes.

(gdb) file examples/freertos-demo/build/freertos-demo.elf
Reading symbols from examples/freertos-demo/build/freertos-demo.elf...
(gdb) target remote localhost:2331
Remote debugging using localhost:2331
task_b (
/home/jkent/tmp/arm-none-eabi/.build/arm-none-eabi/src/gdb/gdb/frame.c:587:
internal-error: frame_id get_frame_id(frame_info*): Assertion `stashed' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug breakpoints/26019] FreeRTOS task breakpoint causes core dump

[jeff at jkent dot net]

https://sourceware.org/bugzilla/show_bug.cgi?id=26019

Jeff Kent <jeff at jkent dot net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jeff at jkent dot net

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug breakpoints/26019] FreeRTOS task breakpoint causes core dump

[jeff at jkent dot net]

https://sourceware.org/bugzilla/show_bug.cgi?id=26019

--- Comment #8 from Jeff Kent <jeff at jkent dot net> ---
Instead of the remote GDB server by appointment, I'm willing to buy, test, and
dispatch hardware if someone is interested in working this bug -- it is a major
show stopper for me. (I want to get to working on USB Device code in FreeRTOS!)

Hardware includes:
  LeapFrog Didj Console
  Adafruit JTAG/SWD Breakout PCB

Optionally, I can include:
  Segger J-Link EDU mini (Comes with JTAG/SWD cable)
  9v AC adapter with US plug
  USB->3.3v UART adapter

I'll wire up the breakout for the JTAG on the Didj as I did with my test unit.
I'll also breakout UART0 and the boot mode pins. I'll make sure everything
works.  The Didj may be in rough shape. Serious takers only!

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug breakpoints/26019] FreeRTOS task breakpoint causes core dump

[jeff at jkent dot net]

https://sourceware.org/bugzilla/show_bug.cgi?id=26019

--- Comment #9 from Jeff Kent <jeff at jkent dot net> ---
Since changing how I load code to my target I have not been able to reproduce
this bug (Though probably another bug, I occasionally get an assertion failure
on quit).  It may have been a desync between the monitor and GDB.  My target's
reset is broken because of DMA holding the processor in reset while it does its
startup thing.  There is a boot mode that lets you start from RAM.  I'm going
to try that and report back, possibly closing this bug.

-- 
You are receiving this mail because:
You are on the CC list for the bug.