Startup Crash in [@ XPCConvert::JSData2Native]
Categories
(Core :: XPConnect, defect, critical)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox-esr60 | --- | unaffected |
| firefox67 | --- | unaffected |
| firefox68 | --- | unaffected |
| firefox69 | blocking | fixed |
People
(Reporter: denschub, Assigned: emk)
References
(Regression)
Details
(Keywords: crash, regression)
Crash Data
Attachments
(1 file)
|
167 bytes,
text/html
|
Details |
This bug is for crash report bp-e6293cc9-457e-40e4-acef-24fbd0190612.
Top 3 frames of crashing thread:
0 XUL XPCConvert::JSData2Native js/xpconnect/src/XPCConvert.cpp
1 XUL XPCWrappedNative::CallMethod js/xpconnect/src/XPCWrappedNative.cpp:1157
2 XUL XPC_WN_CallMethod js/xpconnect/src/XPCWrappedNativeJSOps.cpp:943
Fresh profiles are not affected by this, but my "regular" profile crashes on startup. Given the graph on Socorro, I'm possibly not the only one.
mozregression shows this is a regression from bug 1557254, so I'm flagging it as such for now. Let me know if/how I can extract useful and relevant information out of my profile!
|
Reporter | |
Comment 1•6 months ago
|
||
(Maybe tracking is not needed, this seems to be a Nightly/DevEd only patch causing this crash. Feel free to remove the flags. :))
|
||
Comment 2•6 months ago
|
||
If the code in the "regressing" bug is correct, this is flagging up broken APIs that are probably already not working right for your profile even before this change.
Can you run a local build and get an actual stack and/or JS stack (DumpJSStack() in lldb (with call) or MSVS (in the "Immediate" window)) for that call?
|
||
Updated•6 months ago
|
|
||
Comment 3•6 months ago
|
||
I'm hitting this on Nightly on macOS 10.14 (3 times in the last 30 minutes.)
https://crash-stats.mozilla.org/report/index/51a2e766-f358-478e-90d3-3d10b0190612
Will try and get a JS stack.
|
|
Reporter | |
Comment 4•6 months ago
|
||
Looks like it's hitting the crash on restoring session cookies:
0 restore(cookies = [unavailable]) ["resource:///modules/sessionstore/SessionCookies.jsm":63:27]
1 restore(cookies = [object Object],[object Object], ...
That profile has 5 pinned tabs, including GitHub and Google Mail, so I'm not sure how useful that info is without more details. I'll try to figure out which cookie is breaking things.
|
|
Reporter | |
Comment 5•6 months ago
|
||
Huh, well. It wasn't a cookie of one of the pinned tabs, but rather a cookie set by my favorite airports parking portal. This is the offending cookie:
{
host: "parken.flughafen-stuttgart.de",
value: "\uFFFD",
path: "/",
name: "currsymbol",
originAttributes: {
firstPartyDomain: "",
inIsolatedMozBrowser: false,
privateBrowsingId: 0,
userContextId: 0
}
}
After deleting that cookie in an older build, the new Nightly seems to work just fine.
|
|
||
Comment 6•6 months ago
|
||
Bug 1557254 has been backed out and Nightly respins are underway.
|
|
||
Comment 7•6 months ago
|
||
I ran the latest central in a debugger on my main profile and hit the crash. DumpJSStack() got me the following with the end of the output appearing to be truncated.
0 generateHash(aString = "{
"guid":"root________",
"title":"", "index":0, "dateAdded":1446578012870000,
"lastModified":1556657712886000,
"id":1,
"typeCode":2,
"type":"text/x-moz-place-container",
"root":"placesRoot",
"children": [
{
"guid":"menu________",
"title":"BookmarksMenu",
"index":0,
"dateAdded":1446578012870000,
"lastModified":1554357197366000,
"id":2,
"typeCode":2,
"type":"text/x-moz-place-container",
"root":"bookmarksMenuFolder",
"children":
[
{
"guid":"g097-3nLZdZZ",
"title":"RecentlyBookmarked",
"index":0,
"dateAdded":1416095523956000,
"lastModified":1484943751646000,
"id":24,
"typeCode":1,
"type":"text/x-moz-place",
"uri":"place:parent=menu________&parent=unfiled_____&parent=toolbar_____&queryType=1&sort=12&maxResults=10&excludeQueries=1"},
{
"guid":"QAz1ltxAU3qj",
"title":"Recent Tags",
"index":1,
"dateAdded":1460741748077000,
"lastModified":1460741748093000,
"id":699,
"typeCode":1,
"type":"text/x-moz-place",
"uri":"place:type=6&sort=14&maxResults=10"
},
{
"guid":"z10vlK0NUXXK",
"title":"",
"index":2,
"dateAdded":1455235111979000,
"lastModified":1455235111979000,
"id":597,
"typeCode":3,
"type":"text/x-moz-place-separator"
},
{
"guid":"wA9MZto16D1h",
"title":"Searchfox (s)",
"index":3,
"dateAdded":1465339090801000,
"lastModified":1522702660975000,
"id":749,
"typeCode":1,
"charset":"UTF-8",
"type":"text/x-moz-place",
"uri":"http://searchfox.org/mozilla-central/search?q=%s&path=",
"keyword":"s",
"postData":null
},
{
"guid":"riQidyGnO770",
"title":"Searchfox (p)",
"index":4,
"dateAdded":1554357197366000,
"lastModified":1554357197366000,
"id":943,
"typeCode":1,
"type":"text/x-moz-place",
"uri":"http://searchfox.org/mozilla-central/search?q=&path=%s",
"keyword":"p",
"postData":null
},
{
"guid":"utvkjEleCegk",
"title":"Searchfox (x)",
"index":5,
"dateAdded":1486601318075000,
"lastModified":1554357375637000,
"id":899,
"typeCode":1,
"type":"text/x-moz-place",
"uri":"javascript:var%C2%A0s='%s'; url='https://searchfox.org/mozilla-central/search?q=%s&path=%s'; t=''; qc=0; chunks=url.split('%s'); for(i=0; i<s.length; i++){if(s.charAt(i)=='\"')qc=qc^1; t+=((s.charAt(i)==' '&&qc)?'^':s.charAt(i)); }a
Native crash/stack:
Process 89018 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
frame #0 XUL`XPCConvert::JSData2Native() at XPCConvert.cpp:438
435
436 static void CheckCharsInCharRange(const char16_t* chars, size_t len) {
437 if (!IsUTF16Latin1(MakeSpan(chars, len))) {
-> 438 MOZ_CRASH("char16_t out of char range; high bits of data lost");
439 }
440 }
441 # endif // STRICT_CHECK_OF_UNICODE
Target 0: (firefox) stopped.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
* frame #0 XUL`XPCConvert::JSData2Native() at XPCConvert.cpp:438
frame #1 XUL`XPCConvert::JSData2Native() at XPCConvert.cpp:627
frame #2 XUL`XPCWrappedNative::CallMethod() at XPCWrappedNative.cpp:1572
frame #3 XUL`XPCWrappedNative::CallMethod() at XPCWrappedNative.cpp:1485
frame #4 XUL`XPCWrappedNative::CallMethod() at XPCWrappedNative.cpp:1183
frame #5 XUL`XPCWrappedNative::CallMethod() at XPCWrappedNative.cpp:1157
frame #6 XUL`XPC_WN_GetterSetter() at xpcprivate.h:1486
frame #7 XUL`XPC_WN_GetterSetter() at XPCWrappedNativeJSOps.cpp:974
frame #8 XUL`js::InternalCallOrConstruct() at Interpreter.cpp:448
frame #9 XUL`js::InternalCallOrConstruct() at Interpreter.cpp:540
|
|
Reporter | |
Comment 8•6 months ago
|
||
Looking at Haik's stack, there likely are multiple issues in play here, but for my issue, the cookie contained an euro sign, not the replacement char shown in my initial output. The attached testcase sets a cookie with € as its value, which reliably crahses SessionRestore. Maybe that's useful, maybe not.
|
|
||
Comment 9•6 months ago
|
||
(In reply to Dennis Schubert [:denschub] from comment #8)
Created attachment 9071680 [details]
Test case: SessionRestore crash with cookie containing "€"Looking at Haik's stack, there likely are multiple issues in play here, but for my issue, the cookie contained an euro sign, not the replacement char shown in my initial output. The attached testcase sets a cookie with
€as its value, which reliably crahses SessionRestore. Maybe that's useful, maybe not.
Thanks, this is helpful. It looks like Haik's issue is related to this code: https://searchfox.org/mozilla-central/rev/227f5329f75bd8b16c6b146a7414598a420260cb/toolkit/components/places/BookmarkJSONUtils.jsm#39 where we create a string input stream to serialize bookmarks JSON and compute an MD5 hash from it, and the string input stream's "data" setter can also lose data passed by the caller (I'm guessing, but presumably non-ascii things in the serialized JSON output).
In both cases, I suspect these are real data-losing (ie some text will be lost) bugs that already exist, but obviously the crashes made them a lot more obvious...
|
||
Updated•5 months ago
|
|
||
Comment 10•4 months ago
|
||
While unable to reproduce the crash, I've noticed that on affected builds(such as 68.0b14_Win10) the symbol if the cookie is set to true changes to "�" if setting the HttpOnly value to true.
Assuming that this is part of the issue caused.
With current builds 69.0b8 and the current Nightly build, I am unable to get a crash and the above mentioned scenario is fixed.
Checked with Win10, macOS 10.14, Ubuntu16.04.
Marking this bug as verified since there weren't any crashes with the curent builds.
Description
•