[Bug gdb/10944] Assertion `get_frame_type (frame) == DUMMY_FRAME' failed

[Bug gdb/10944] Assertion `get_frame_type (frame) == DUMMY_FRAME' failed

[domen at cba dot si]

http://sourceware.org/bugzilla/show_bug.cgi?id=10944

Domen Puncer <domen at cba dot si> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|7.0                         |7.2

--- Comment #1 from Domen Puncer <domen at cba dot si> 2011-03-24 08:04:45 UTC ---
I can also reliably reproduce (well... at least some part of backtrace looks
similar) this with:
GNU gdb (GDB) 7.2
This GDB was configured as "--host=x86_64-unknown-linux-gnu
--target=arm-none-eabi".

With a function call:
(gdb) call usart_puts(2, "ATZ")
infrun.c:5509: internal-error: normal_stop: Assertion `get_frame_type (frame)
== DUMMY_FRAME' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) y
infrun.c:5509: internal-error: normal_stop: Assertion `get_frame_type (frame)
== DUMMY_FRAME' 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)


(gdb) bt
#0  0x00007f3679373a75 in *__GI_raise (sig=<value optimized out>) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1  0x00007f36793775c0 in *__GI_abort () at abort.c:92
#2  0x0000000000410d26 in dump_core () at utils.c:1010
#3  0x0000000000411b6a in internal_vproblem (problem=0x961020, file=<value
optimized out>, line=<value optimized out>, fmt=<value optimized out>,
ap=<value optimized out>) at utils.c:1176
#4  0x0000000000411d39 in internal_verror (file=<value optimized out>,
line=<value optimized out>, fmt=<value optimized out>, ap=0x1caa380) at
utils.c:1191
#5  0x0000000000411dd1 in internal_error (file=0x2b81 <Address 0x2b81 out of
bounds>, line=11137, string=0x6 <Address 0x6 out of bounds>) at utils.c:1201
#6  0x00000000004c98a2 in normal_stop () at infrun.c:5509
#7  0x00000000004bf8d0 in run_inferior_call (call_thread=0x1ba7b80,
real_pc=<value optimized out>) at infcall.c:378
#8  0x00000000004c04be in call_function_by_hand (function=<value optimized
out>, nargs=<value optimized out>, args=<value optimized out>) at infcall.c:804
#9  0x0000000000496645 in evaluate_subexp_standard (expect_type=<value
optimized out>, exp=<value optimized out>, pos=0x20, noside=<value optimized
out>) at eval.c:1784
#10 0x000000000053eaf5 in evaluate_subexp_c (expect_type=0x2b81, exp=0x2b81,
pos=0x6, noside=<value optimized out>) at c-lang.c:1047
#11 0x0000000000494d82 in evaluate_subexp (exp=0x2b81) at eval.c:76
#12 evaluate_expression (exp=0x2b81) at eval.c:167
#13 0x00000000004ab359 in print_command_1 (exp=0x1b90e65 "usart_puts(2,
\"ATZ\")", inspect=0, voidprint=0) at ./printcmd.c:969
#14 0x000000000040fc9d in execute_command (p=0x1b90e78 ")", from_tty=1) at
top.c:422
#15 0x00000000004dec88 in command_handler (command=0x1b90e60 "call
usart_puts(2, \"ATZ\")") at event-top.c:498
#16 0x00000000004df86c in command_line_handler (rl=<value optimized out>) at
event-top.c:702
#17 0x00000000005ce6c7 in rl_callback_read_char () at callback.c:205
#18 0x00000000004decf9 in rl_callback_read_char_wrapper (client_data=0x2b81) at
event-top.c:178
#19 0x00000000004dd708 in process_event () at event-loop.c:399
(gdb)

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug gdb/10944] Assertion `get_frame_type (frame) == DUMMY_FRAME' failed

[tschwinge at sourceware dot org]

http://sourceware.org/bugzilla/show_bug.cgi?id=10944

Thomas Schwinge <tschwinge at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tschwinge at sourceware dot
                   |                            |org

--- Comment #2 from Thomas Schwinge <tschwinge at sourceware dot org> 2012-08-02 09:22:04 UTC ---
Is there still someone available who can reliably reproduce this?  Are
you by chance experiencing these GDB crashes on multicore ARM processors?

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug gdb/10944] Assertion `get_frame_type (frame) == DUMMY_FRAME' failed

[jan.kratochvil at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=10944

Jan Kratochvil <jan.kratochvil at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jan.kratochvil at redhat
                   |                            |dot com

--- Comment #3 from Jan Kratochvil <jan.kratochvil at redhat dot com> 2012-08-11 19:52:49 UTC ---
Not sure what is the problem there but with native arm gdb it works for me:

GNU gdb (GDB) 7.4.50.20120620-cvs
This GDB was configured as "armv7l-unknown-linux-gnueabihf".
(gdb) p f (2, "ATZ")
$1 = void

testfile: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked
(uses shared libs), for GNU/Linux 2.6.32,
BuildID[sha1]=0x4f2be64687db897e3bc8a5f03e68d0b8bc09dfcd, not stripped

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug gdb/10944] Assertion `get_frame_type (frame) == DUMMY_FRAME' failed

[tschwinge at sourceware dot org]

http://sourceware.org/bugzilla/show_bug.cgi?id=10944

--- Comment #4 from Thomas Schwinge <tschwinge at sourceware dot org> 2012-08-12 08:38:55 UTC ---
Jan, this had been reported for an arm-none-eabi target, not a
Linux-based one.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug gdb/10944] Assertion `get_frame_type (frame) == DUMMY_FRAME' failed

[jan.kratochvil at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=10944

--- Comment #5 from Jan Kratochvil <jan.kratochvil at redhat dot com> 2012-08-12 08:57:11 UTC ---
GNU gdb (GDB) 7.5.50.20120812-cvs
This GDB was configured as "--host=x86_64-unknown-linux-gnu
--target=arm-none-eabi".
Reading symbols from /home/jkratoch/redhat/gdb-clean/gdb/1...done.
(gdb) target remote virt:1234
Remote debugging using virt:1234
warning: A handler for the OS ABI "GNU/Linux" is not built into this
configuration of GDB.  Attempting to continue with the default arm settings.
0x43608de0 in ?? ()
(gdb) b main
Cannot access memory at address 0x0
Breakpoint 1 at 0x859c: file 1.c, line 5.
(gdb) c
Continuing.

Breakpoint 1, main () at 1.c:5
5    int main (void) { return 0; }
(gdb) p f (2, "ATZ")
$1 = void
(gdb) b f
Breakpoint 2 at 0x855c: file 1.c, line 2.
(gdb) p f (2, "ATZ")
Breakpoint 2, f (x=2, s=0x11018 "ATZ") at 1.c:2
2    void f (int x, const char *s) {}
The program being debugged stopped while in a function called from GDB.
Evaluation of the expression containing the function
(f) will be abandoned.
When the function is done executing, GDB will silently stop.
(gdb) bt
#0  f (x=2, s=0x11018 "ATZ") at 1.c:2
#1  <function called from gdb>
#2  main () at 1.c:5
(gdb) l
1    #include <stdlib.h>
2    void f (int x, const char *s) {}
3    void *malloc (size_t size)
4    { return realloc (NULL, size); }
5    int main (void) { return 0; }

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug gdb/10944] Assertion `get_frame_type (frame) == DUMMY_FRAME' failed

[tschwinge at sourceware dot org]

http://sourceware.org/bugzilla/show_bug.cgi?id=10944

--- Comment #6 from Thomas Schwinge <tschwinge at sourceware dot org> 2012-08-12 10:35:59 UTC ---
Is this a multi-core/hardware-multi-threaded system?  And where is the
dummy frame's return breakpoint set?  I have seen and fixed this issue on
another (unpublished) GDB port where the dummy call's return breakpoint
was the entry point at address 0, and another hardware-thread would hit
that one, which thusly confused GDB.  Moving the dummy call's return onto
the thread's stack was the solution, by adding a push_dummy_code function
and »set_gdbarch_call_dummy_location (gdbarch, ON_STACK);«.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug gdb/10944] Assertion `get_frame_type (frame) == DUMMY_FRAME' failed

[jan.kratochvil at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=10944

--- Comment #7 from Jan Kratochvil <jan.kratochvil at redhat dot com> 2012-08-12 10:57:11 UTC ---
#1  <function called from gdb>
(gdb) p/x $pc
$2 = 0x8414
(gdb) info sym 0x8414
_start in section .text

x86* has also switched now to ON_STACK, could you post this patch to
gdb-patches with some regression testing on appropriate ARM platform?

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug gdb/10944] Assertion `get_frame_type (frame) == DUMMY_FRAME' failed

[tschwinge at sourceware dot org]

http://sourceware.org/bugzilla/show_bug.cgi?id=10944

--- Comment #8 from Thomas Schwinge <tschwinge at sourceware dot org> 2012-08-13 10:39:26 UTC ---
I'm sorry I don't have a patch for ARM (and at the moment I'm not in the
position for creating and testing one) -- mine was for a different
(unpublished) target.  Also, we have not determined this is really the
problem being hit here.  (Though, generally using ON_STACK may be a
reasonable change in itself.)

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug gdb/10944] Assertion `get_frame_type (frame) == DUMMY_FRAME' failed

[tuben at lysator dot liu.se]

http://sourceware.org/bugzilla/show_bug.cgi?id=10944

Johan Tufvesson <tuben at lysator dot liu.se> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tuben at lysator dot liu.se

--- Comment #9 from Johan Tufvesson <tuben at lysator dot liu.se> 2012-12-11 08:08:45 UTC ---
I think that I see this problem all the time using an ARM Cortex-M3 with a
FlashPro4 JTAG from Microsemi. The connection to the JTAG is done through an
"arm-none-eabi-sprite" from the CodeSourcery environment. No multiple cores
here. It is possible to make one call into the inferior (using call or print),
but when returning from the second call GDB chokes. I'm quite new to both the
GDB and ARM environment, but everything works as expected when running the
target. I'm only having trouble when calling into the inferior from GDB, and
the problem is always exactly as below, the second call into the inferior.

If I take a step after the first call returned, I can make a second call
without problems. If I then take another step, a third call can be made. The
problem only occurs (with 100% certainty) at the second call from the same
spot.

I would be very grateful for any help on this, and would be happy to try out a
patch. The GDB 7.5.1 in this case have been built by me, but the faulty
behavior is exactly the same using binaries from the CodeSourcery or Yagarto
tool chains.

GNU gdb (GDB) 7.5.1
Copyright (C) 2012 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=i686-pc-mingw32 --target=arm-none-eabi".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
0x60080404 in ?? ()
Loading section .intvec, size 0x298 lma 0x60000000
Loading section .text, size 0x1674 lma 0x60000298
Loading section .rdata, size 0x178 lma 0x6000190c
Loading section .data, size 0x60 lma 0x60001a84
Start address 0x298, load size 6884
Transfer rate: 9 KB/sec, 62 bytes/write.
(gdb) thb main
Hardware assisted breakpoint 1 at 0x1694: file src/main.c, line 50.
(gdb) cont
Continuing.

Temporary breakpoint 1, main () at src/main.c:50
50         UP_RegisterInit();
(gdb) bt
#0  main () at src/main.c:50
(gdb) break test_TimeOut
Breakpoint 2 at 0x16d4: file src/test.c, line 70.
(gdb) call test_TimeOut()
Note: automatically using hardware breakpoints for read-only addresses.

Breakpoint 2, test_TimeOut () at src/test.c:70
70         test_bTimerCount++;
(gdb) The program being debugged stopped while in a function called from GDB.
Evaluation of the expression containing the function
(test_TimeOut) will be abandoned.
When the function is done executing, GDB will silently stop.
bt
#0  test_TimeOut () at src/test.c:70
#1  <function called from gdb>
#2  main () at src/main.c:50
(gdb) cont
Continuing.
(gdb) bt
#0  main () at src/main.c:50
(gdb) call test_TimeOut()

Breakpoint 2, test_TimeOut () at src/test.c:70
70         test_bTimerCount++;
(gdb) The program being debugged stopped while in a function called from GDB.
Evaluation of the expression containing the function
(test_TimeOut) will be abandoned.
When the function is done executing, GDB will silently stop.
bt
#0  test_TimeOut () at src/test.c:70
#1  0x00000298 in IntVec ()
#2  0x00000298 in IntVec ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) cont
Continuing.
infrun.c:6092: internal-error: normal_stop: Assertion `get_frame_type (frame)
== DUMMY_FRAME' 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]
infrun.c:6092: internal-error: normal_stop: Assertion `get_frame_type (frame)
== DUMMY_FRAME' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Create a core file of GDB? (y or n) [answered Y; input not from terminal]

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.