The nsDOMClassInfo.cpp can't access JSScopeProperty when JS_THREADSAFE is turned off

RESOLVED FIXED in mozilla1.9

Status

()

Core
JavaScript Engine
P2
normal
RESOLVED FIXED
10 years ago
10 years ago

People

(Reporter: gyuyoung kim, Assigned: brendan)

Tracking

Trunk
mozilla1.9
Points:
---
Bug Flags:
in-testsuite -
in-litmus -

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 2 obsolete attachments)

(Reporter)

Description

10 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; ko; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12
Build Identifier: 

 I met a compilation error on nsDOMClassInfo.cpp file when I turned off the JS_THREADSAFE. The reason is that nsWindowSH::AddProperty function can't use the struct JSScopeProperty.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.
(Reporter)

Updated

10 years ago
Version: unspecified → Other Branch
(Reporter)

Comment 1

10 years ago
Created attachment 306888 [details] [diff] [review]
v1

As mentioned in the bug 412985 comment 27, I modified the patch by considering jason's comment. 

In jslock.h file, I can't move "#include "jsscope.h" to top of the file.
Because, If #include "jsscope.h" is moved so, the struct JSScope in jsscope.h can't access struct JSThinLock. So, I moved #include "jsscope.h" to out of #ifdef JS_THREADSAFE ~ #endif as the patch.

I'd like to get an advice about this patch.
(Reporter)

Updated

10 years ago
Attachment #306888 - Flags: review?(jorendorff)
(Assignee)

Comment 2

10 years ago
Comment on attachment 306888 [details] [diff] [review]
v1

Now that JSTitle has been factored from JSScope, could we not get rid of the #include cycle between jslock.h and jsscope.h, by having jslock.h *not* include jsscope.h conditionally any longer?

This would be great. Any dependent files that want both jslock.h and jsscope.h would have to #include both. That may already be satisfied by current #includes.

/be
(In reply to comment #2)
Looks like removing the #include "jsscope.h" from jslock.h and adding it to jscntxt.h works.

The latter is necessary because of another cycle: the macros OBJ_GET_SLOT and OBJ_SET_SLOT, defined in jsobj.h, require OBJ_SCOPE and struct JSScope from jsscope.h, which includes jsobj.h.  jscntxt.h was previously getting jsscope.h anyway, via jslock.h via jsatom.h.
(Assignee)

Comment 4

10 years ago
Better to reduce nesting. Macros do not expand until called, so if there are only a few, or ideally no, calls that occur in files that do not include jsscope.h, then why not avoid nesting #include "jsscope.h" anywhere? Currently AFAICT it is nested only in jslock.h.

/be
Status: UNCONFIRMED → NEW
Ever confirmed: true
Created attachment 307312 [details] [diff] [review]
v2

Here's an updated patch.

Gyu-young, please check that this works for you.  I built the browser with this patch, but I didn't try to build it without JS_THREADSAFE.  (I did build js shell both ways.)
Attachment #306888 - Attachment is obsolete: true
Attachment #307312 - Flags: review?(brendan)
Attachment #306888 - Flags: review?(jorendorff)
(Assignee)

Comment 6

10 years ago
Created attachment 307323 [details] [diff] [review]
alternative patch avoids over-including

Sorry, this was my old mess. I'll clean it up if you agree with this approach. Thanks,

/be
Assignee: general → brendan
Attachment #307312 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #307323 - Flags: review?(jorendorff)
Attachment #307312 - Flags: review?(brendan)
Comment on attachment 307323 [details] [diff] [review]
alternative patch avoids over-including

Yes.
Attachment #307323 - Flags: review?(jorendorff) → review+
(Assignee)

Comment 8

10 years ago
This is a safe change to header file and #ifdef relations, wanted by Samsung. It can go in ASAP without rocking any boats.

/be
Flags: blocking1.9?
(Assignee)

Updated

10 years ago
Priority: -- → P2
Target Milestone: --- → mozilla1.9
Version: Other Branch → Trunk
(Assignee)

Comment 9

10 years ago
Comment on attachment 307323 [details] [diff] [review]
alternative patch avoids over-including

Bug should not be a blocker, patch just wants approval.

/be
Attachment #307323 - Flags: approval1.9?
(Assignee)

Updated

10 years ago
Flags: blocking1.9?
Attachment #307323 - Flags: approval1.9? → approval1.9+
(Assignee)

Comment 10

10 years ago
Fixed:

js/src/jsatom.h 3.83
js/src/jsexn.c 3.99
js/src/jslock.h 3.42
js/src/jsnum.c 3.110
js/src/jsregexp.c 3.190
js/src/jsstr.c 3.198

/be
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED

Comment 11

10 years ago
It seems this caused:

c:\slave\trunk_2k3\mozilla\js\src\xpconnect\src\xpcinlines.h(746) : error C3861: 'ID_TO_VALUE': identifier not found
c:\slave\trunk_2k3\mozilla\js\src\xpconnect\src\xpcinlines.h(746) : error C3861: 'ID_TO_VALUE': identifier not found
NEXT ERROR make[5]: *** [nsXPConnect.obj] Error 2
make[5]: *** Waiting for unfinished jobs....
c:\slave\trunk_2k3\mozilla\js\src\xpconnect\src\xpcinlines.h(746) : error C3861: 'ID_TO_VALUE': identifier not found
(Reporter)

Comment 12

10 years ago
Created attachment 307508 [details] [diff] [review]
v1

I think Brendan patch can take place a compilation error. As mentioned in Mr. Bukanov, xpcinlines.h can't use an ID_TO_VALUE macro provided by jsscope.h.

(With the Firefox 3.0 beta 3, I want to test it with the latest firefox but I can't because of some compilation errors in other module)

In order to solve this problem, I added #include “jsscope.h” to a xpcprivate.h. 
Because, Xpcinlines.h included jsscope.h through a xpcprivate.h that has a jscntxt.h. but, a jscntxt.h doesn’t include a jsscope.h any longer.
(Reporter)

Updated

10 years ago
Attachment #307508 - Flags: review?(brendan)
(Assignee)

Comment 13

10 years ago
I moved ID_TO_VALUE to jsprvtd.h right under the *JSID* macros (it really should be named like them, but later). Please update your tree and re-test.

/be
(Assignee)

Comment 14

10 years ago
Comment on attachment 307508 [details] [diff] [review]
v1

Should not be necessary, is not in a threadsafe build. If a single-threaded (JS_THREADSAFE not defined) build has some problem(s), please show the failing make's output. Thanks,

/be
Attachment #307508 - Flags: review?(brendan) → review-
(Reporter)

Comment 15

10 years ago
I think the building firefox without JS_THREADSAFE is left modification of XPConnect. So,I reported a bug for this problem. 

Bug 421481 – XPConnect can't be built without JS_THREADSAFE.

Updated

10 years ago
Flags: in-testsuite-
Flags: in-litmus-
You need to log in before you can comment on or make changes to this bug.