This is the mail archive of the gdb-prs@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug gdb/17384] android arm gdb "Cannot access memory at address" when I "stepi" over "blx"


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

--- Comment #10 from molsson <martin at minimum dot se> ---
I put a breakpoint just below the comment "We have no symbol information" that
I mentioned earlier, and then I ran the code on an AOSP device. And indeed that
block runs even on AOSP. So presence of debuginfo doesn't seem to be what makes
the behavioral difference in AOSP vs non-AOSP; making what you said about
optimization levels an even more likely explanation.

>From a high-level perspective it feels wrong to force the user to
recompile/reinstall his OS just to be able to debug his application; so it
would be really nice if some ARM expert tagged along and asked me the right
questions to allow us to tweak the heuristics sufficiently.

---

Also, regarding safe_read_memory_integer() printing errors I should say that
there is more to that part of the bug than just the fact that the error is
printed. This is because after I type "next" and get the error, I cannot just
run "next" again; at that point gdb just constantly prints "Cannot find bounds
of current function" and refuses to move forward; like this:

Breakpoint 1, blink::RenderFullScreen::createPlaceholder (this=0x34038100,
style=..., frameRect=...) at
../../third_party/WebKit/Source/core/rendering/RenderFullScreen.cpp:188
188        if (style->width().isAuto())
(gdb) n
Cannot access memory at address 0x1
0x4e128838 in ?? () from
/media/ssd/src/opera/opera/chromium/src/out_generic_armv7/Debug/lib/libblink_web.cr.so
(gdb) n
Cannot find bounds of current function
(gdb)

...however, if I run "stepi" three times consecutively I can get out of this
weird state and make gdb get "unstuck" (until the next function call where it
typically gets "stuck" again, needing more "stepi" to continue). Like this:

Breakpoint 1, blink::RenderFullScreen::createPlaceholder (this=0x80238100,
style=..., frameRect=...) at
../../third_party/WebKit/Source/core/rendering/RenderFullScreen.cpp:188
188        if (style->width().isAuto())
(gdb) n
0x7a6c5838 in ?? () from
/media/ssd/src/opera/opera/chromium/src/out_generic_armv7/Debug/lib/libblink_web.cr.so
(gdb) n
Cannot find bounds of current function
(gdb) n
Cannot find bounds of current function
(gdb) stepi
0x7a6c583c in ?? () from
/media/ssd/src/opera/opera/chromium/src/out_generic_armv7/Debug/lib/libblink_web.cr.so
(gdb) stepi
0x7a6c5840 in ?? () from
/media/ssd/src/opera/opera/chromium/src/out_generic_armv7/Debug/lib/libblink_web.cr.so
(gdb) stepi
WTF::RefPtr<WTF::StringImpl>::get (this=0x0) at
../../third_party/WebKit/Source/wtf/OwnPtr.h:71
71            PtrType get() const { return m_ptr; }
(gdb) n
0x7a6bff00 in ?? () from
/media/ssd/src/opera/opera/chromium/src/out_generic_armv7/Debug/lib/libblink_web.cr.so
(gdb) stepi
0x7a6bff04 in ?? () from
/media/ssd/src/opera/opera/chromium/src/out_generic_armv7/Debug/lib/libblink_web.cr.so
(gdb) stepi
0x7a6bff08 in ?? () from
/media/ssd/src/opera/opera/chromium/src/out_generic_armv7/Debug/lib/libblink_web.cr.so
(gdb) stepi
blink::Length::isAuto (this=0x37a90ca8) at
../../third_party/WebKit/Source/platform/Length.h:274
274        bool isAuto() const { return type() == Auto; }
(gdb) n
blink::RenderFullScreen::createPlaceholder (this=0x80238100, style=...,
frameRect=...) at
../../third_party/WebKit/Source/core/rendering/RenderFullScreen.cpp:189
189            style->setWidth(Length(frameRect.width(), Fixed));
(gdb) n

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]