JS GDB unwinder fails with `Python Exception <class 'KeyError'> ('per_tls_context',)`

RESOLVED FIXED in Firefox 64

Status

()

enhancement
P3
normal
RESOLVED FIXED
11 months ago
6 months ago

People

(Reporter: squib, Assigned: squib)

Tracking

unspecified
mozilla64
Points:
---

Firefox Tracking Flags

(firefox64 fixed)

Details

Attachments

(6 attachments, 4 obsolete attachments)

46 bytes, text/x-phabricator-request
tromey
: review+
Details | Review
46 bytes, text/x-phabricator-request
tromey
: review+
Details | Review
46 bytes, text/x-phabricator-request
tromey
: review+
Details | Review
46 bytes, text/x-phabricator-request
tromey
: review+
Details | Review
46 bytes, text/x-phabricator-request
tromey
: review+
Details | Review
46 bytes, text/x-phabricator-request
tromey
: review+
Details | Review
Assignee

Description

11 months ago
I think there are multiple issues hiding just beneath this, but the most immediate problem is that the gdb unwinder throws `Python Exception <class 'KeyError'> ('per_tls_context',)` when adding `masm.breakpoint();` to `BaselineCompiler::emitBinaryArith` and running:

  ./jit-test/jit_test.py BUILD-DEBUG/dist/bin/js --args='--no-ion --ion-offthread-compile=off' basic/testDoubleToStr.js -g
Assignee

Comment 1

11 months ago
And here's the full traceback from Python:

Traceback (most recent call last):
  File "/usr/share/gdb/python/gdb/__init__.py", line 91, in execute_unwinders
    unwind_info = unwinder(pending_frame)
  File "/home/jim/src/mozilla-central/js/src/gdb/mozilla/unwind.py", line 594, in __call__
    return self.unwinder_state.unwind(pending_frame)
  File "/home/jim/src/mozilla-central/js/src/gdb/mozilla/unwind.py", line 501, in unwind
    return self.unwind_exit_frame(pc, pending_frame)
  File "/home/jim/src/mozilla-central/js/src/gdb/mozilla/unwind.py", line 456, in unwind_exit_frame
    cx = self.get_tls_context()
  File "/home/jim/src/mozilla-central/js/src/gdb/mozilla/unwind.py", line 376, in get_tls_context
    return self.typecache.per_tls_context.value()['mValue']
  File "/home/jim/src/mozilla-central/js/src/gdb/mozilla/unwind.py", line 70, in __getattr__
    return self.d[name]
KeyError: 'per_tls_context'
Traceback (most recent call last):
  File "/usr/share/gdb/python/gdb/__init__.py", line 91, in execute_unwinders
    unwind_info = unwinder(pending_frame)
  File "/home/jim/src/mozilla-central/js/src/gdb/mozilla/unwind.py", line 594, in __call__
    return self.unwinder_state.unwind(pending_frame)
  File "/home/jim/src/mozilla-central/js/src/gdb/mozilla/unwind.py", line 501, in unwind
    return self.unwind_exit_frame(pc, pending_frame)
  File "/home/jim/src/mozilla-central/js/src/gdb/mozilla/unwind.py", line 456, in unwind_exit_frame
    cx = self.get_tls_context()
  File "/home/jim/src/mozilla-central/js/src/gdb/mozilla/unwind.py", line 376, in get_tls_context
    return self.typecache.per_tls_context.value()['mValue']
  File "/home/jim/src/mozilla-central/js/src/gdb/mozilla/unwind.py", line 69, in __getattr__
    self.initialize()
  File "/home/jim/src/mozilla-central/js/src/gdb/mozilla/unwind.py", line 77, in initialize
    self.d['FRAMETYPE_MASK'] = (1 << self.value('FRAMETYPE_BITS')) - 1
  File "/home/jim/src/mozilla-central/js/src/gdb/mozilla/unwind.py", line 73, in value
    return long(gdb.parse_and_eval('js::jit::' + name))
gdb.error: No type "jit" within class or namespace "js".
Assignee

Comment 2

11 months ago
:jimb, it was suggested that I ping you about this. I'd like to get this fixed, since I think it will help me fix the remaining issues in bug 1401624. I don't have much experience with the JS engine, and even less about the gdb unwinder, so just consider this a sanity check for now. :) It's entirely possible I'm just doing something wrong here. If there's any extra info you need, just let me know!
Flags: needinfo?(jimb)

Comment 3

11 months ago
Tom, it seems like UnwinderTypeCache.initialize is unable to look up the constants in js/src/jit/JitFrames.h. I don't know why that would be the case, they're still defined there.
Flags: needinfo?(jimb) → needinfo?(ttromey)
Assignee

Comment 4

11 months ago
Yeah, that's one thing I noticed. The other issue (there are actually two exceptions above) is that during initialization of the UnwinderTypeCache, the plugin tries to use the 'per_tls_context', which isn't initialized yet.[1] I tried initializing the 'per_tls_context' first, but the error with finding FRAMETYPE_MASK and friends still occurs.  I'm not sure if this has an "obvious" solution or not, hence my filing a bug before I spend too much time on it. I'm happy to spend some time reading up on gdb plugins though if the fix is more-complex.

[1] This *seems* wrong to me, but maybe it's ok; it looks like we're trying to unwind the stack while we're initializing the UnwinderTypeCache, which was in turn prompted by... unwinding the stack.

Comment 5

11 months ago
> gdb.error: No type "jit" within class or namespace "js".

I'm doing a build so I can try it out, but from this error my first
thought is that maybe the name lookups are not being done
using the correct language.
Assignee

Comment 6

11 months ago
:tromey, thanks for the tip. I changed our usage of `gdb.parse_and_eval(...)` to `gdb.lookup_symbol(...)[0].value()`, and that failure goes away. With my attached patch, I now get the following errors. It looks like we have 2 issues: 1) we're trying to use 'per_tls_context' before we've actually initialized it, and 2) when we try to get the actual value out of 'per_tls_context', gdb gets mad because we didn't give it a frame to compute the value (I'm guessing this is because the value is thread-local and gdb can't figure out what thread we want to look in?).

Traceback (most recent call last):
  File "/usr/share/gdb/python/gdb/__init__.py", line 91, in execute_unwinders
    unwind_info = unwinder(pending_frame)
  File "/home/jim/src/mozilla-central/js/src/gdb/mozilla/unwind.py", line 598, in __call__
    return self.unwinder_state.unwind(pending_frame)
  File "/home/jim/src/mozilla-central/js/src/gdb/mozilla/unwind.py", line 505, in unwind
    return self.unwind_exit_frame(pc, pending_frame)
  File "/home/jim/src/mozilla-central/js/src/gdb/mozilla/unwind.py", line 460, in unwind_exit_frame
    cx = self.get_tls_context()
  File "/home/jim/src/mozilla-central/js/src/gdb/mozilla/unwind.py", line 380, in get_tls_context
    return self.typecache.per_tls_context.value()['mValue']
  File "/home/jim/src/mozilla-central/js/src/gdb/mozilla/unwind.py", line 71, in __getattr__
    return self.d[name]
KeyError: 'per_tls_context'
Traceback (most recent call last):
  File "/usr/share/gdb/python/gdb/__init__.py", line 91, in execute_unwinders
    unwind_info = unwinder(pending_frame)
  File "/home/jim/src/mozilla-central/js/src/gdb/mozilla/unwind.py", line 598, in __call__
    return self.unwinder_state.unwind(pending_frame)
  File "/home/jim/src/mozilla-central/js/src/gdb/mozilla/unwind.py", line 505, in unwind
    return self.unwind_exit_frame(pc, pending_frame)
  File "/home/jim/src/mozilla-central/js/src/gdb/mozilla/unwind.py", line 460, in unwind_exit_frame
    cx = self.get_tls_context()
  File "/home/jim/src/mozilla-central/js/src/gdb/mozilla/unwind.py", line 380, in get_tls_context
    return self.typecache.per_tls_context.value()['mValue']
gdb.error: symbol requires a frame to compute its value

Thread 1 "js" received signal SIGTRAP, Trace/breakpoint trap.
Traceback (most recent call last):
  File "/usr/share/gdb/python/gdb/__init__.py", line 91, in execute_unwinders
    unwind_info = unwinder(pending_frame)
  File "/home/jim/src/mozilla-central/js/src/gdb/mozilla/unwind.py", line 598, in __call__
    return self.unwinder_state.unwind(pending_frame)
  File "/home/jim/src/mozilla-central/js/src/gdb/mozilla/unwind.py", line 505, in unwind
    return self.unwind_exit_frame(pc, pending_frame)
  File "/home/jim/src/mozilla-central/js/src/gdb/mozilla/unwind.py", line 460, in unwind_exit_frame
    cx = self.get_tls_context()
  File "/home/jim/src/mozilla-central/js/src/gdb/mozilla/unwind.py", line 380, in get_tls_context
    return self.typecache.per_tls_context.value()['mValue']
gdb.error: symbol requires a frame to compute its value
Assignee

Comment 7

11 months ago
Regarding the (potential?) language issue with `gdb.parse_and_eval(...)`, I wonder if it's because it's being called while I was (I think) inside JITed code, so maybe gdb was trying to infer the language from my position in the stack and couldn't figure it out. I'm not 100% clear on how parse_and_eval works...

Comment 8

11 months ago
(In reply to Jim Porter (:squib) from comment #7)
> Regarding the (potential?) language issue with `gdb.parse_and_eval(...)`, I
> wonder if it's because it's being called while I was (I think) inside JITed
> code, so maybe gdb was trying to infer the language from my position in the
> stack and couldn't figure it out. I'm not 100% clear on how parse_and_eval
> works...

This is a possible scenario but I hacked `gdb.execute("show language")`
into `UnwinderTypeCache.initialize` and it shows that the language is C++ there.
Flags: needinfo?(ttromey)

Comment 9

11 months ago
(In reply to Jim Porter (:squib) from comment #6)
> 2) when we try to get the actual
> value out of 'per_tls_context', gdb gets mad because we didn't give it a
> frame to compute the value (I'm guessing this is because the value is
> thread-local and gdb can't figure out what thread we want to look in?).

What version of gdb are you using?
I fixed this exact bug in 2016 as part of this unwinder work:
https://sourceware.org/bugzilla/show_bug.cgi?id=20190

However I wonder if it has resurfaced somehow.
Also, what platform are you on?

Comment 10

11 months ago
Your patch helps here, too.  I get different failures from you though:

Traceback (most recent call last):
  File "/usr/local/stow/my-gdb/share/gdb/python/gdb/__init__.py", line 91, in execute_unwinders
    unwind_info = unwinder(pending_frame)
  File "/home/tromey/firefox-git/hg2/js/src/gdb/mozilla/unwind.py", line 598, in __call__
    return self.unwinder_state.unwind(pending_frame)
  File "/home/tromey/firefox-git/hg2/js/src/gdb/mozilla/unwind.py", line 505, in unwind
    return self.unwind_exit_frame(pc, pending_frame)
  File "/home/tromey/firefox-git/hg2/js/src/gdb/mozilla/unwind.py", line 465, in unwind_exit_frame
    packedExitFP = self.activation['packedExitFP_']
gdb.error: There is no member named packedExitFP_.
0x000031c28a7bfe12 in ?? ()
Traceback (most recent call last):
  File "/usr/local/stow/my-gdb/share/gdb/python/gdb/__init__.py", line 91, in execute_unwinders
    unwind_info = unwinder(pending_frame)
  File "/home/tromey/firefox-git/hg2/js/src/gdb/mozilla/unwind.py", line 598, in __call__
    return self.unwinder_state.unwind(pending_frame)
  File "/home/tromey/firefox-git/hg2/js/src/gdb/mozilla/unwind.py", line 505, in unwind
    return self.unwind_exit_frame(pc, pending_frame)
  File "/home/tromey/firefox-git/hg2/js/src/gdb/mozilla/unwind.py", line 456, in unwind_exit_frame
    if self.activation == 0:
gdb.error: Invalid type combination in equality test.

Comment 11

11 months ago
Also, the unwinder can't really be used when the newest frame is a JIT frame.
The reason is that it would need a heuristic to find the frame descriptor,
and I was reluctant to do this as it seemed to error-prone.
If you need this to debug something, though, you might be able to hack it in.
Also if frame pointers are ever turned on, then this restriction could be lifted.
Assignee

Comment 12

11 months ago
(In reply to Tom Tromey :tromey from comment #8)
> This is a possible scenario but I hacked `gdb.execute("show language")`
> into `UnwinderTypeCache.initialize` and it shows that the language is C++
> there.

I get `The current source language is "auto; currently c".` But maybe that's because my gdb is too old...

(In reply to Tom Tromey :tromey from comment #9)
> What version of gdb are you using?
> I fixed this exact bug in 2016 as part of this unwinder work:
> https://sourceware.org/bugzilla/show_bug.cgi?id=20190

Murphy's Law; I'm on gdb 7.11 and it looks like I need 7.12. I'll upgrade gdb and see if things are any better...

I'm on 64-bit Linux (Mint 18.3, which is based on Ubuntu 16.04).
Assignee

Comment 13

11 months ago
Ok, I upgraded to gdb 8.1.0 and the 'per_tls_context' issue is fixed; now I see the same issue as you with 'packedExitFP_'. (gdb still infers the language as "auto; currently c" though.) I'll keep banging on this to see if I can at least get it to stop throwing exceptions, and then I'll try to figure out a way to make the unwinder work when the newest frame is in JIT. If you have any suggestions for that, I'd be happy to hear them. :)
Assignee

Comment 14

11 months ago
Ok, this at least gets me to the point where running and breaking inside JIT code doesn't raise any Python exceptions. Notable things I did:

* Use gdb.lookup_symbol instead of gdb.parse_and_eval (the latter thinks we're in C code and gets confused)
* Add a reference to `JitFrame_JSJitToWasm`
* Fetch the actual `JitActivation`, which is now hiding inside a `ProtectedData` instance

Still to do:
* Improve the unwinder so that it understands when the newest stack frame is in JIT code
* Detect the gdb version and emit a warning if it's too old (hopefully this will help people in the future who try to use this on an old gdb and run into the 'per_tls_context' error I hit)
Assignee: nobody → jporter+bmo
Attachment #9001356 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #9001468 - Flags: feedback?(ttromey)
Assignee

Comment 15

11 months ago
Oh, one other to-do that I forgot to list (which may just fall under "improve the unwinder"). Fix it so that Python doesn't raise an exception when trying to print the backtrace. This is what I get now with my patch:

Traceback (most recent call last):
  File "/usr/share/gdb/python/gdb/__init__.py", line 91, in execute_unwinders
    unwind_info = unwinder(pending_frame)
  File "/home/jim/src/mozilla-central/js/src/gdb/mozilla/unwind.py", line 598, in __call__
    return self.unwinder_state.unwind(pending_frame)
  File "/home/jim/src/mozilla-central/js/src/gdb/mozilla/unwind.py", line 501, in unwind
    return self.unwind_ordinary(pc, pending_frame)
  File "/home/jim/src/mozilla-central/js/src/gdb/mozilla/unwind.py", line 451, in unwind_ordinary
    self.next_type, pending_frame)
  File "/home/jim/src/mozilla-central/js/src/gdb/mozilla/unwind.py", line 422, in create_frame
    (local_size, header_size, next_type) = self.unpack_descriptor(common)
  File "/home/jim/src/mozilla-central/js/src/gdb/mozilla/unwind.py", line 388, in unpack_descriptor
    value = long(common['descriptor_'])
gdb.MemoryError: Cannot access memory at address 0x8002c3112c36

Comment 16

10 months ago
Comment on attachment 9001468 [details] [diff] [review]
Fix all the issues causing Python exceptions to be raised when breaking in JIT code

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

Looks good to me.  Thank you for doing this.
Attachment #9001468 - Flags: feedback?(ttromey) → feedback+

Comment 17

10 months ago
(In reply to Jim Porter (:squib) from comment #15)
> Oh, one other to-do that I forgot to list (which may just fall under
> "improve the unwinder"). Fix it so that Python doesn't raise an exception
> when trying to print the backtrace. This is what I get now with my patch:
[...]

I wonder if this is because you're stopping in a JIT frame and so
the descriptor isn't being found properly?

One simple way to test is to debug the js shell, put a breakpoint in Print,
then evaluate some js code that calls print().  At the breakpoint,
bt ought to work fine with the unwinder enabled.

Comment 18

10 months ago
(In reply to Jim Porter (:squib) from comment #14)

> * Improve the unwinder so that it understands when the newest stack frame is
> in JIT code

I think it really can't be done reliably until frame pointers are in.
(Bug 1426134 is where that work is being done.)

The issue is that there's no way to find the CommonLayout object given
just the information we have: the values of the registers in the newest
frame, and the stack.

A heuristic would be to look for two words where one is a plausible return
address and the next is a plausible descriptor value (and maybe try to unwind
one more frame and see if the next descriptor is also plausible).

> * Detect the gdb version and emit a warning if it's too old (hopefully this
> will help people in the future who try to use this on an old gdb and run
> into the 'per_tls_context' error I hit)

gdb doesn't document it but it provides the version in Python:

(gdb) python print(repr(gdb.VERSION))
'8.0.50.20170911-git'

Unfortunately you have to parse this.

Another possibility is to look for a Python feature that shipped in the same
release as the bug fix you are interested in.  From the 7.12 release notes:

  ** Three new breakpoint-related events have been added:
     gdb.breakpoint_created, gdb.breakpoint_modified, and
     gdb.breakpoint_deleted.

So you could check for the existence of one of these.

Hah, I see this is already done for something else:
https://dxr.mozilla.org/mozilla-central/source/js/src/gdb/mozilla/unwind.py#554-555
Assignee

Comment 19

10 months ago
Quick question that I'm putting at the top so it doesn't get missed: do we run tests on Treeherder to make sure our gdb plugin keeps working? It seems like there's a fair amount of bitrot here...

(In reply to Tom Tromey :tromey from comment #17)
> One simple way to test is to debug the js shell, put a breakpoint in Print,
> then evaluate some js code that calls print().  At the breakpoint,
> bt ought to work fine with the unwinder enabled.

I'm working through this now, though it looks like there are a bunch of other issues. Right now, I'm seeing that JSString's internals have changed, so the pretty printer is failing. Just for reference, here's what I'm doing: first, I run with `gdb --args BUILD-DEBUG/dist/bin/js --baseline-eager`, and then I just paste the following commands into gdb:

set python print-stack full
enable unwinder .* SpiderMonkey
break js.cpp:Print
r
function f() { console.log('hi'); }
for (let i = 0; i < 1; i++) { f(); }
bt

I do get some stack frames that look like they're from our unwinder, so that's good. The other errors are not so good, and I'll try and get them fixed.
Flags: needinfo?(ttromey)
Assignee

Comment 20

10 months ago
Ok, this resolves the other Python exceptions I was seeing. There were some layout changes to various types in the JS engine that the gdb plugin hadn't been updated to understand. Next, I'll start taking a look at how to at least improve things when the newest frame is a JIT frame.
Attachment #9001468 - Attachment is obsolete: true

Comment 21

10 months ago
(In reply to Jim Porter (:squib) from comment #19)
> Quick question that I'm putting at the top so it doesn't get missed: do we
> run tests on Treeherder to make sure our gdb plugin keeps working? It seems
> like there's a fair amount of bitrot here...

There are tests, but I imagine they aren't run on try, because things seem to break
and not be noticed.  They are in js/src/gdb/tests/

> I'm working through this now, though it looks like there are a bunch of
> other issues. Right now, I'm seeing that JSString's internals have changed,

This is bug 1482844.

Enabling the unwinder by default is bug 1290898, which I forgot existed.

Comment 22

10 months ago
Clearing NI.
Flags: needinfo?(ttromey)

Comment 23

10 months ago
Comment on attachment 9002059 [details] [diff] [review]
Fix backtraces from C++ that unwind through (baseline) JIT code

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

This all looks good to me, but be sure to try the tests manually if you haven't already.
Priority: -- → P3
Assignee

Comment 24

10 months ago
(In reply to Tom Tromey :tromey from comment #23)
> This all looks good to me, but be sure to try the tests manually if you
> haven't already.

Yep, I'm going through those now. They appear to be pretty busted, but I'm still investigating why.

Comment 25

10 months ago
Feel free to deal with the other bustage in separate bugs. No need to morph this into a mega-bug.
(In reply to Jim Porter (:squib) from comment #19)
> Quick question that I'm putting at the top so it doesn't get missed: do we
> run tests on Treeherder to make sure our gdb plugin keeps working? It seems
> like there's a fair amount of bitrot here...

No. Quite a while back, I created a job to do this, but our CI machine images don't have gdb so I needed to install it -- which wasn't hard to do using the system package manager, except that the OS version was so old that its latest gdb update was too old for our prettyprinters. I started working on a toolchain-like job to compile a newer gdb, but ended up getting pulled off to other things before I got it all working.

Anyway, things are better now. If there isn't an easy-to-install compatible gdb available, it's much much easier these days to create a toolchain job to create one. (Or pull in a precompiled binary through tooltool, though for most things it seems we've been trying to move to toolchain jobs instead.)

Bug 1255476.
Assignee

Comment 28

10 months ago
This updates the pretty-printer for JSStrings to account for the internal
changes in bug 1479900.

Depends on D4607
Assignee

Comment 29

10 months ago
This accounts for changes to the layout of JS::Value from bug 1449051.

Depends on D4608
Assignee

Comment 31

10 months ago
This accounts for internal hash table changes in bug 1478896 and bug 1462261.

Depends on D4610
Assignee

Comment 32

10 months ago
Bug 1464036 changed how JSID_EMPTY was defined; this patch updates the gdb
plugin accordingly.

Depends on D4611
Assignee

Comment 33

10 months ago
Commenting out some breakpoints because they're breaking things in the unit
tests and I'm not sure why yet.

Depends on D4612
Assignee

Updated

10 months ago
Attachment #9002059 - Attachment is obsolete: true

Comment 34

10 months ago
Comment on attachment 9005043 [details]
Bug 1483323 part 1 - Fix initializing the SpiderMonkey gdb UnwinderTypeCache r=tromey

Tom Tromey :tromey has approved the revision.
Attachment #9005043 - Flags: review+

Comment 35

10 months ago
Comment on attachment 9005045 [details]
Bug 1483323 part 3 - Fix fetching the scriptsourceobj in the gdb plugin r=tromey

Tom Tromey :tromey has approved the revision.
Attachment #9005045 - Flags: review+

Comment 36

10 months ago
Comment on attachment 9005048 [details]
Bug 1483323 part 6 - Fix recognizing JSID_EMPTY r=tromey

Tom Tromey :tromey has approved the revision.
Attachment #9005048 - Flags: review+

Comment 37

10 months ago
Comment on attachment 9005046 [details]
Bug 1483323 part 4 - GCC emits typedefs in DWARF now r=tromey

Tom Tromey :tromey has approved the revision.
Attachment #9005046 - Flags: review+

Comment 38

10 months ago
Comment on attachment 9005044 [details]
Bug 1483323 part 2 - Fix pretty-printing of JSStrings r=tromey

Tom Tromey :tromey has approved the revision.
Attachment #9005044 - Flags: review+

Comment 39

10 months ago
Comment on attachment 9005047 [details]
Bug 1483323 part 5 - Fix ExecutableAllocator pretty printer r=tromey

Tom Tromey :tromey has approved the revision.
Attachment #9005047 - Flags: review+

Updated

10 months ago
Attachment #9005049 - Attachment is obsolete: true
Assignee

Comment 40

10 months ago
This should be ready to land. I'd click the button myself, but my commit access lapsed since I was working on stuff on GitHub prior to this. I filed bug 1488514 to get access restored.

:tromey, if everything looks good to land to you, would you mind landing this while I wait for my commit access back? Thanks!
Flags: needinfo?(ttromey)

Comment 41

10 months ago
I don't mind but I don't actually know how to land things from phabricator.
I read the Lando guide but it wasn't clear if there is a simpler way to land
a series than visiting the patches one by one.
Flags: needinfo?(ttromey)
Assignee

Comment 42

10 months ago
To be honest, I don't know either. I'm used to MozReview...

Comment 43

10 months ago
On #lando I was told to push directly, because using lando one-by-one was wasteful
(and in general possibly incorrect because a series may have an invalid intermediate state).

I'm not very comfortable with direct pushes (haven't done one in years) so I am going to
use checkin-needed instead, I'm afraid.
Keywords: checkin-needed
Hello, i tried to land the above patches, but for the first one got https://irccloud.mozilla.com/file/KxDoLDaI/image.png 

Please fix it and readd the checkin-needed after. 
Thank you.
Flags: needinfo?(jporter+bmo)
Keywords: checkin-needed
Assignee

Comment 45

10 months ago
Well... almost all the unit tests are broken again, so I'm going to see if I can fix them at least to ensure that the basics work right. Hopefully I'll be able to catch up to what's live in central. :/
Flags: needinfo?(jporter+bmo)
Assignee

Comment 46

10 months ago
Nevermind, it turns out I was just on the wrong branch! Things should be ready to land, and I verified that the gdb unit tests pass locally. They won't pass for other people unless they comment out some breakpoints in our jit code, but the plugin should work for people in real-world scenarios; I'll file a followup bug to track this part.
Keywords: checkin-needed

Comment 47

10 months ago
Pushed by apavel@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/c32643cc46b6
part 1 - Fix initializing the SpiderMonkey gdb UnwinderTypeCache r=tromey
Keywords: checkin-needed

Comment 48

10 months ago
Pushed by apavel@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/4fb8cbcedcb1
part 2 - Fix pretty-printing of JSStrings r=tromey

Comment 49

10 months ago
Pushed by apavel@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/056faf94c597
part 3 - Fix fetching the scriptsourceobj in the gdb plugin r=tromey

Comment 50

10 months ago
Pushed by apavel@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/20c3fcfe5b48
part 4 - GCC emits typedefs in DWARF now r=tromey

Comment 51

10 months ago
Pushed by apavel@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/e12d3b4009bf
part 5 - Fix ExecutableAllocator pretty printer r=tromey

Comment 52

10 months ago
Pushed by apavel@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/1f62e4c2870d
part 6 - Fix recognizing JSID_EMPTY r=tromey
Duplicate of this bug: 1482844
You need to log in before you can comment on or make changes to this bug.