public inbox for gdb-prs@sourceware.org help / color / mirror / Atom feed
From: "tuben at lysator dot liu.se" <sourceware-bugzilla@sourceware.org> To: gdb-prs@sourceware.org Subject: [Bug gdb/10944] Assertion `get_frame_type (frame) == DUMMY_FRAME' failed Date: Tue, 11 Dec 2012 08:08:00 -0000 [thread overview] Message-ID: <bug-10944-4717-kSokxtAgZ7@http.sourceware.org/bugzilla/> (raw) In-Reply-To: <bug-10944-4717@http.sourceware.org/bugzilla/> 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.
prev parent reply other threads:[~2012-12-11 8:08 UTC|newest] Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <bug-10944-4717@http.sourceware.org/bugzilla/> 2011-03-24 8:04 ` domen at cba dot si 2012-08-02 9:22 ` tschwinge at sourceware dot org 2012-08-11 19:53 ` jan.kratochvil at redhat dot com 2012-08-12 8:39 ` tschwinge at sourceware dot org 2012-08-12 8:58 ` jan.kratochvil at redhat dot com 2012-08-12 10:36 ` tschwinge at sourceware dot org 2012-08-12 10:57 ` jan.kratochvil at redhat dot com 2012-08-13 10:40 ` tschwinge at sourceware dot org 2012-12-11 8:08 ` tuben at lysator dot liu.se [this message]
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-10944-4717-kSokxtAgZ7@http.sourceware.org/bugzilla/ \ --to=sourceware-bugzilla@sourceware.org \ --cc=gdb-prs@sourceware.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).