Closed
Bug 430581
Opened 17 years ago
Closed 16 years ago
nsString and nsString_external has different size on x86_64
Categories
(Core :: XPCOM, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: mpgritti, Assigned: mpgritti)
Details
(Keywords: fixed1.9.0.2)
Attachments
(1 file, 2 obsolete files)
1.18 KB,
patch
|
benjamin
:
review+
shaver
:
approval1.9-
samuel.sidler+old
:
approval1.9.0.2+
|
Details | Diff | Splinter Review |
It has been fixed on i386 by bug 390849, but it's still different on x86_64.
Because of this, using nsIDocument in an extensions results in hard to debug crashes. For reference https://bugzilla.redhat.com/show_bug.cgi?id=441643
On x86_64:
(gdb) p sizeof ( nsString )
$7 = 16
(gdb) p sizeof ( nsString_external )
$8 = 24
On i386:
(gdb) p sizeof(nsString)
$1 = 12
(gdb) p sizeof(nsString_external)
$2 = 12
Assignee | ||
Updated•17 years ago
|
Version: unspecified → Trunk
Comment 1•17 years ago
|
||
Nominating for blocking because this will affect 64 bit extensions.
Marco, can you produce a patch?
Flags: blocking1.9?
Comment 2•17 years ago
|
||
Why is this just coming up now? Are you suggesting blocking because we can't change this in a dot release?
re-nom when answered?
Comment 3•17 years ago
|
||
I don't think this should block. The frozen string API is working correctly... the struct is big enough, it just happens to be too big. This doesn't break the API directly: it only breaks people who use internal pseudo-interfaces.
Assignee | ||
Comment 5•17 years ago
|
||
Assignee | ||
Updated•17 years ago
|
Attachment #318839 -
Attachment description: Fix (not tested on i386 yet) → Fix
Attachment #318839 -
Flags: review?(benjamin)
Comment 6•17 years ago
|
||
Comment on attachment 318839 [details] [diff] [review]
Fix
I think this is ok, but I'd like a testcase somewhere which asserts that sizeof(nsStringContainer_base) == sizeof(nsSubstring)... I think PR_STATIC_ASSERT can be used to make a compile-time testcase.
Attachment #318839 -
Flags: review?(benjamin) → review-
Assignee | ||
Comment 7•17 years ago
|
||
I'm not sure if nsSubstring.cpp is the best place for the PR_STATIC_ASSERT, better ideas are welcome.
Attachment #318839 -
Attachment is obsolete: true
Assignee | ||
Updated•17 years ago
|
Attachment #322003 -
Flags: review?(benjamin)
Assignee | ||
Updated•17 years ago
|
Attachment #322003 -
Attachment is obsolete: true
Attachment #322003 -
Flags: review?(benjamin)
Assignee | ||
Comment 8•17 years ago
|
||
Attachment #322005 -
Flags: review?
Assignee | ||
Updated•17 years ago
|
Attachment #322005 -
Flags: review? → review?(benjamin)
Updated•17 years ago
|
Attachment #322005 -
Flags: review?(benjamin) → review+
Comment 9•17 years ago
|
||
Comment on attachment 322005 [details] [diff] [review]
Use PR_STATIC_ASSERT to check size at compile time
This is very low-risk and I think we should take it so we can publish the XULRunner 1.9 SDK with the fix.
Attachment #322005 -
Flags: approval1.9?
Updated•17 years ago
|
Whiteboard: [RC2?]
Comment 10•17 years ago
|
||
Comment on attachment 322005 [details] [diff] [review]
Use PR_STATIC_ASSERT to check size at compile time
Per discussion with :bs, not necessary for 3.0, and tbh comments like "untested on x86" make me think that we might want to try it on other platforms a wee bit as well. 3.0.1 will be a fine time to release the 1.9 SDK.
Attachment #322005 -
Flags: approval1.9? → approval1.9-
Updated•17 years ago
|
Whiteboard: [RC2?] → [RC2-]
Assignee | ||
Comment 11•17 years ago
|
||
Just to clarify, I tested it on x86 before submitting it for review.
Comment 12•17 years ago
|
||
Hey Marco: if this is to be considered for 3.0.1 we'll need:
- complete assessment of risk, and what testing was done to mitigate
- an approval1.9.0.1 request
Assignee | ||
Comment 13•17 years ago
|
||
Comment on attachment 322005 [details] [diff] [review]
Use PR_STATIC_ASSERT to check size at compile time
As far as I can tell this is very low risk (Benjamin agrees with that in comment #9). If there are issues the PR_STATIC_ASSERT should catch them. I tested it both on x86 and x86_64.
Attachment #322005 -
Flags: approval1.9.0.1?
Updated•17 years ago
|
Attachment #322005 -
Flags: approval1.9.0.1? → approval1.9.0.2?
Comment 14•16 years ago
|
||
Can we get this landed on m-c (resolve it as FIXED when that's done) before approving for 1.9.0.x?
Assignee | ||
Comment 15•16 years ago
|
||
What does m-c stand for?
Comment 16•16 years ago
|
||
mozilla-central
Assignee | ||
Comment 17•16 years ago
|
||
Ok. I'll try to get a mozilla-central account.
Comment 18•16 years ago
|
||
(In reply to comment #17)
> Ok. I'll try to get a mozilla-central account.
Alternatively, someone else can check this in for you.
Keywords: checkin-needed
Updated•16 years ago
|
Assignee: nobody → mpgritti
Comment 19•16 years ago
|
||
Marco is working on fixing his Hg access (he should have access already).
Status: NEW → ASSIGNED
Keywords: checkin-needed
Updated•16 years ago
|
Whiteboard: [RC2-] → [needs mozilla central landing before 1.9 approval]
Comment 20•16 years ago
|
||
We need to get this landed in mozilla-central soon if you want it in 1.9.0.2.
Assignee | ||
Comment 21•16 years ago
|
||
Landed on mozilla-central. Sorry for the delay and thanks for reminding me about it.
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Updated•16 years ago
|
Whiteboard: [needs mozilla central landing before 1.9 approval] → [needs baking]
Updated•16 years ago
|
Whiteboard: [needs baking]
Comment 22•16 years ago
|
||
Comment on attachment 322005 [details] [diff] [review]
Use PR_STATIC_ASSERT to check size at compile time
Approved for 1.9.0.2. Please land in CVS. a=ss
Attachment #322005 -
Flags: approval1.9.0.2? → approval1.9.0.2+
Comment 23•16 years ago
|
||
Marco, if you want this in 1.9.0.2, we need it landed asap.
Assignee | ||
Updated•16 years ago
|
Keywords: fixed1.9.0.2
You need to log in
before you can comment on or make changes to this bug.
Description
•