This is the mail archive of the
gdb-prs@sourceware.org
mailing list for the GDB project.
[Bug gdb/17384] android arm gdb "Cannot access memory at address" when I "stepi" over "blx"
- From: "palves at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: gdb-prs at sourceware dot org
- Date: Tue, 16 Sep 2014 09:16:51 +0000
- Subject: [Bug gdb/17384] android arm gdb "Cannot access memory at address" when I "stepi" over "blx"
- Auto-submitted: auto-generated
- References: <bug-17384-4717 at http dot sourceware dot org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=17384
--- Comment #3 from Pedro Alves <palves at redhat dot com> ---
I'm not exactly sure what's going on here, but the backtrace shows a memory
read coming from the prologue scanner, triggered probably from the code that
tries to determine whether the program stepped into a function:
#2 0x000000000058be11 in read_memory (memaddr=1,
...
#5 0x0000000000513225 in catch_errors (func=func@entry=0x58bef0
...
#6 0x000000000058be8b in safe_read_memory_integer (memaddr=<optimized out>,
#7 0x000000000041122a in arm_scan_prologue (cache=0x1e51ec0,
#8 arm_make_prologue_cache (this_frame=0x1e51e00) at arm-tdep.c:2022
...
#12 0x00000000005e72ca in get_prev_frame_always_1 (this_frame=0x1e51470) at
frame.c:1955
...
#15 0x0000000000503a07 in process_event_stop_test
(ecs=ecs@entry=0x7fff5dee9070) at infrun.c:4738
So it kind of sounds like either the program's stack really is corrupted, or,
GDB's heuristic prologue scanner gets this prologue wrong.
But the thing is that error you've shown is caught and swallowed (frames
#5/#6),
so it looks like this particular memory_error call can't result in the user
visible error. There's probably another one after if you let GDB continue.
--
You are receiving this mail because:
You are on the CC list for the bug.