Closed Bug 1259867 Opened 4 years ago Closed 4 years ago

gdb unwinder throws when in rr

Categories

(Core :: JavaScript Engine, defect)

defect
Not set

Tracking

()

RESOLVED FIXED
mozilla48
Tracking Status
firefox48 --- fixed

People

(Reporter: mrbkap, Assigned: nbp)

References

(Blocks 1 open bug)

Details

Attachments

(1 file, 2 obsolete files)

I was debugging Firefox in an rr recording today with the JS gdb helpers enabled when I started getting a ton of errors complaining that /proc/<pid>/maps didn't exist. Some quick searching led me to js/src/gdb/mozilla/unwind.py, where it does:

    mapfile = '/proc/' + str(gdb.selected_inferior().pid) + '/maps'
    ...
    with open(mapfile, "r") as inp:

However, for rr, I can't even find a maps file for my trace (only a mmaps file, which appears to be in a binary format and that is in a directory under my home).

I've disabled the gdb helpers locally, but it would be good if we either detected what was going on and dealt with it or at least caught the error and handled it more gracefully.
Flags: needinfo?(nicolas.b.pierron)
Yeah, this area needs a bit of love, sorry about that.
I forgot that "target remote" debugging is actually common here :(

I think the idea from https://bugzilla.mozilla.org/show_bug.cgi?id=1255884#c1
will probably do the trick here.
(In reply to Blake Kaplan (:mrbkap) (please use needinfo!) from comment #0)
> I was debugging Firefox in an rr recording today with the JS gdb helpers
> enabled […]

Out of curiosity, are you loading the /dist/bin/*-gdb.py file manually?

I was unable to get rr do it automatically, because it looks for the binary path, which got copied over to the ~/.rr directory, without copying the corresponding *-gdb.py file.
Ok, another issue is that currently rr does not expose TLS information through the remote debugger protocol.

Thus, even if we were to use a different strategy, the fact that we rely on js::TlsPerThreadData to find the jitActivations will cause us other issues.

I guess we could use this slot as a probe for rr, while it is being implemented, and while we are moving away from the /proc/*/maps file.
(In reply to Nicolas B. Pierron [:nbp] from comment #2)
> (In reply to Blake Kaplan (:mrbkap) (please use needinfo!) from comment #0)
> > I was debugging Firefox in an rr recording today with the JS gdb helpers
> > enabled […]
> 
> Out of curiosity, are you loading the /dist/bin/*-gdb.py file manually?

I didn't do anything manually. I set my auto-load safe-path to /, so maybe it was picking it up from the srcdir somehow?

I'm also on Arch Linux, which stores the rr data in ~/.local/share/rr if that matters.
I'm also seeing this error when debugging with rr and I didn't do anything to load our gdb scripts manually. I'm launching rr replay from the objdir, which has a .gdbinit file, so maybe that matters.
I got a lot of errors from gdb 7.10.1, while running the following test
case:

function f() { return a == Math.sin(5) && !inIon(); }
var a = Math.sin(5);
while (f()) ;


With the following gdb script:


b js::jit::CodeGenerator::generateBody
b js::math_sin
disable 2
run
enable 2
continue
backtrace


The error I got are the following:


Starting program: /home/nicolas/mozilla/_build/js/bugzil.la/1258397/commit/x64/gcc48/dbg/js/src/js ./foo.js
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/nix/store/n2wxp513rr00f6hr2dy0waqahns49dch-glibc-2.21/lib/libthread_db.so.1".
linux-thread-db.c:1675: internal-error: find_new_threads_once: Assertion `!target_has_execution || thread_db_use_events ()' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.


I have no idea what I should do to work around this issue within the
unwinder.
Attachment #8736421 - Flags: feedback?(ttromey)
Comment on attachment 8736421 [details] [diff] [review]
GDB Scripts: Replace /proc/maps by TLS lookup of Jit informations. r=

For me this patch makes gdb lock up, due to an infinite recursion:
it is trying to evaluate an expression ("js::jit::FRAMETYPE_BITS"),
which tries to get the frame, which tries to invoke the unwinders, etc.

Anyway I think the general idea of this patch is great.  I just wonder
if we can somehow force these expression lookups before the first time
we need to unwind.  The comment I added in UnwinderTypeCache.__getattr__
suggests that maybe there's a gdb bug here to be worked around.

It would be interesting maybe to see the gdb stack trace at the assertion
failure point.  Perhaps that would give more clues.
Attachment #8736421 - Flags: feedback?(ttromey) → feedback+
Attachment #8737196 - Flags: review?(ttromey)
Comment on attachment 8737196 [details] [diff] [review]
GDB Hooks: Disable SpiderMonkey's unwinder by default.

Review of attachment 8737196 [details] [diff] [review]:
-----------------------------------------------------------------

I think it should work to set "self.enabled = False" in the SpiderMonkeyUnwinder constructor.
On irc you mentioned that this didn't work but why?  It seems like it should.

The output could move there as well, so that if we ever enable it by default it will be obvious
that the print should be removed.

Also, does this still pass the test suite?  I would expect it to need a test update to enable
the unwinder.
Attachment #8737196 - Flags: review?(ttromey) → review-
Attachment #8737196 - Attachment is obsolete: true
Comment on attachment 8737258 [details] [diff] [review]
GDB Scripts: Disable SpiderMonkey's unwinder by default.

Review of attachment 8737258 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good, thanks.

I still wonder if the test case works.
Attachment #8737258 - Flags: review?(ttromey) → review+
Flags: needinfo?(nicolas.b.pierron)
Comment on attachment 8736421 [details] [diff] [review]
GDB Scripts: Replace /proc/maps by TLS lookup of Jit informations. r=

This patch moved to Bug 1261426.
Attachment #8736421 - Attachment is obsolete: true
Assignee: nobody → nicolas.b.pierron
Status: NEW → ASSIGNED
https://hg.mozilla.org/mozilla-central/rev/9861363aaea9
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla48
Blocks: 1290898
You need to log in before you can comment on or make changes to this bug.