417818 - js shell doesn't build with JS_DEBUG_TITLE_LOCKS

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Jason Orendorff [:jorendorff]]

Two problems:

1. JS_DEBUG_SCOPE_LOCKS still appears in jslock.h

2. JS_LOCK_OBJ wants SET_OBJ_INFO() to be an expression; it isn't.

Comment 1

[Jason Orendorff [:jorendorff]]

Attachment: non-working patch

I don't have time to figure out why this isn't working for me right now.  Compiles fine.

Comment 2

[Jason Orendorff [:jorendorff]]

Seems like js_TransferTitle is being called with
  oldTitle == (JSTitle *)0x0000000c.

Comment 3

[Jason Orendorff [:jorendorff]]

Filed bug 418041 for the weirdness I was seeing in comment 2.

Comment 4

[Jason Orendorff [:jorendorff]]

Attachment: v1

OK, this now WFM.  Only difference from the previous patch is a style nit.

Comment 5

[Mike Shaver (:shaver emeritus)]

Comment on attachment 303871 [details] [diff] [review]
v1

r=shaver, thanks

Comment 6

[Reed Loden [:reed]]

Umm, doesn't this need approval first? Feel free to re-add the keyword if that's not right.

Comment 7

[Brendan Eich [:brendan]]

Comment on attachment 303871 [details] [diff] [review]
v1

Reed, you monkey -- this is righteous debug-only #ifdef'ed stuff -- do not stand in its way!

/be

Comment 8

[Reed Loden [:reed]]

(In reply to comment #7)
> (From update of attachment 303871 [details] [diff] [review])
> Reed, you monkey -- this is righteous debug-only #ifdef'ed stuff -- do not
> stand in its way!

With the ridiculous number of |#ifdef|s in JS code, it's hard to tell what's really debug only. Just felt it was better to ask. ;)

I'll land this later today.

Comment 9

[Brendan Eich [:brendan]]

Toughen up, your #ifdef skills are weak :-P. Seriously, if you see JS_DEBUG_* or JS_*_METERING in the #ifdef (in addition to DEBUG*), that's NPOTB.

/be

Comment 10

[Brendan Eich [:brendan]]

I just landed this:

js/src/jslock.c 3.81
js/src/jslock.h 3.41

/be

Comment 11

[Christian Haider]

I just tried to use some JS components on different treads. Unfortunately I experienced some strange behaviour. Since my build of TB and FF crashed in or somewhere near jslock.c I thought I post it here.
I'm not sure if it is a bug, but I think what I try to do should work.

I wrote a component in C++. This component starts a new thread with NS_NewThread(getter_AddRefs(workerThread),NULL); 
Afterwards I dispatch a runnable (also implemented in c++) to the new workerThread. 
what happens then is, if I try to create an object of an component (written in JS) within the run-function TB and FF freeze or crash.

I wrote a tiny extension that should demonstrate what I mean. 
You can download it http://rapidshare.com/files/94071762/jackf.zip.html here and build it.

Comment 12

[Mike Shaver (:shaver emeritus)]

Virtually certain to not be this bug; could you file another one, with stack trace information for all threads at the point of hang or crash?  Thanks!

Comment 13

[Christian Haider]

(In reply to comment #12)
> Virtually certain to not be this bug; could you file another one, with stack
> trace information for all threads at the point of hang or crash?  Thanks!

I filed a new bug. hopefully I picked the right category. https://bugzilla.mozilla.org/show_bug.cgi?id=419192
If it's possible please have a look if I provided all neccacary data.
Thx Chris