From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 523 invoked by alias); 11 Dec 2012 08:08:54 -0000 Received: (qmail 495 invoked by uid 48); 11 Dec 2012 08:08:52 -0000 From: "tuben at lysator dot liu.se" 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 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: gdb X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: tuben at lysator dot liu.se X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: 7.1 X-Bugzilla-Changed-Fields: CC Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact gdb-prs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-prs-owner@sourceware.org X-SW-Source: 2012-q4/txt/msg00364.txt.bz2 http://sourceware.org/bugzilla/show_bug.cgi?id=10944 Johan Tufvesson changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tuben at lysator dot liu.se --- Comment #9 from Johan Tufvesson 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 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: . 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 #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.