Closed Bug 683096 Opened 13 years ago Closed 13 years ago

Error: [Exception... "Could not convert JavaScript argument arg 5 [calIOperationListener.onGetResult]"...

Categories

(Core :: XPCOM, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla9

People

(Reporter: Fallen, Assigned: khuey)

Details

(Whiteboard: [needed beta][no l10n impact])

Attachments

(1 file, 1 obsolete file)

Error: [Exception... "Could not convert JavaScript argument arg 5 [calIOperationListener.onGetResult]"  nsresult: "0x80570009 (NS_ERROR_XPC_BAD_CONVERT_JS)"  location: "JS frame :: file:///Users/kewisch/mozilla/comm-central/obj-x86_64-apple-darwin11.0.0/mozilla/dist/Shredder.app/Contents/MacOS/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/components/calMemoryCalendar.js :: <TOP_LEVEL> :: line 485"  data: no]
Source File: file:///Users/kewisch/mozilla/comm-central/obj-x86_64-apple-darwin11.0.0/mozilla/dist/Shredder.app/Contents/MacOS/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/components/calMemoryCalendar.js
Line: 485

When doing various calendar additions. Also caused a test failure, so this must be from one of the recent checkins.
Flags: blocking-calendar1.0+
Hmm strange. Works on Linux, fails on Mac/Windows. Argument 5 is a PRUint32, so I have no idea why the hell its going wrong. Relevant lines are:

aListener.onGetResult (this.superCalendar,
                       Components.results.NS_OK, 
                       typeIID,
                       null,
                       itemsFound.length
                       itemsFound);
Based on the win32 hourly build log this is the regression range:
https://hg.mozilla.org/comm-central/pushloghtml?fromchange=f4bbdf829ffd&tochange=a728bb065609

Maybe Bug 681720 caused regression on how the interface is created? And maybe only the win32 hourly build fails because it seems to be the only one that was clobbered in the last days?

Wild guess: Is the number in "JavaScript argument arg 5" 0-based or 1-based? In the former case: maybe the new pyxpidl parser doesn't like the line break inside aItems definition?

 627   void onGetResult (in calICalendar aCalendar,
 628                     in nsresult aStatus,
 629                     in nsIIDRef aItemType, 
 630                     in nsIVariant aDetail,
 631                     in PRUint32 aCount, 
 632                     [array, size_is(aCount), iid_is(aItemType)] 
 633                     in nsQIResult aItems );
Attached patch Fix - v1 (obsolete) — Splinter Review
(In reply to Stefan Sitter from comment #2)
> Wild guess: Is the number in "JavaScript argument arg 5" 0-based or 1-based?
> In the former case: maybe the new pyxpidl parser doesn't like the line break
> inside aItems definition?
Hmm strange. I probably missed clearing out the right things, but your idea might actually fix it. I changed that, ran the tests, it worked. Then I popped off the patch, make clean in base/public, make in calendar/lightning, and for some reason it still worked. I think we should try it and see what the tinderboxen say.
Assignee: nobody → philipp
Status: NEW → ASSIGNED
Attachment #557534 - Flags: review?(ssitter)
Comment on attachment 557534 [details] [diff] [review]
Fix - v1

r=ssitter for testing. do you intend to keep the cal.WARN statement?
Attachment #557534 - Flags: review?(ssitter) → review+
Oh no, forgot to qref that patch it seems. Thanks!
Pushed to comm-central <http://hg.mozilla.org/comm-central/rev/71c2f36ca280>
-> FIXED
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → Trunk
> Wild guess: Is the number in "JavaScript argument arg 5" 0-based or 1-based? In the
> former case: maybe the new pyxpidl parser doesn't like the line break inside aItems
> definition?
File a bug?
Unfortunately it doesn't seem to help. Now Linux shows the same error, maybe because the checkin caused a rebuild http://tinderbox.mozilla.org/showbuilds.cgi?tree=CalendarTrunk

TEST-UNEXPECTED-FAIL | (xpcshell/head.js) | [Exception... "Could not convert JavaScript argument arg 5 [calIOperationListener.onGetResult]"  nsresult: "0x80570009 (NS_ERROR_XPC_BAD_CONVERT_JS)"  location: "JS frame :: file:///builds/buildbot/comm-central-lightning-linux/build/objdir-tb/mozilla/dist/bin/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/components/calStorageCalendar.js :: cSC_getItem :: line 634"  data: no]
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
I'm 95% sure this is a bug in the new IDL compiler.
Assignee: philipp → khuey
Component: Internal Components → XPCOM
Flags: blocking-calendar1.0+
Product: Calendar → Core
QA Contact: base → xpcom
Target Milestone: Trunk → ---
Yep, definitely a bug in the IDL compiler.  We're not handling array's of nsQIResults.  Patch forthcoming.
Attached patch PatchSplinter Review
Attachment #557534 - Attachment is obsolete: true
Attachment #557802 - Flags: review?(ted.mielczarek)
Are the tests in mozilla/js/src/xpconnect/ related to or used by this component?

https://mxr.mozilla.org/comm-central/source/mozilla/js/src/xpconnect/tests/idl/xpctest.idl#230 defines a test method that is similar to the one defined by Lightning code. Therefore I assumed the new idl compiler still supports this.
There's some in js/src/xpconnect/tests/js, but I don't think those are running ...
Attachment #557802 - Flags: review?(ted.mielczarek) → review+
http://hg.mozilla.org/mozilla-central/rev/e5815c156b6c
Status: REOPENED → RESOLVED
Closed: 13 years ago13 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla9
The whole b-s merge backed out of m-c for causing bustage:
http://hg.mozilla.org/mozilla-central/rev/472716252ea3

https://tbpl.mozilla.org/?usebuildbot=1&rev=e5815c156b6c
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Target Milestone: mozilla9 → ---
http://hg.mozilla.org/mozilla-central/rev/a351ae35f2c4
Status: REOPENED → RESOLVED
Closed: 13 years ago13 years ago
OS: Mac OS X → All
Hardware: x86 → All
Resolution: --- → FIXED
Target Milestone: --- → mozilla9
You need to log in before you can comment on or make changes to this bug.