Closed Bug 499568 Opened 15 years ago Closed 15 years ago

uncaught exception: 2147500033

Categories

(Firefox Graveyard :: RSS Discovery and Preview, defect)

Product:
Firefox Graveyard
Component:
RSS Discovery and Preview
Version:
3.5 Branch
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 452317

People

(Reporter: johnjbarton, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [firebug-p3]) 

I get this error message:
uncaught exception: 2147500033@file:///C:/Program%20Files/Mozilla%20Firefox%203.5RC1/components/nsLivemarkService.js:609.0
repeated multiple times. At the same time my CPU goes to 100%.

It seems to start when Firebug opens. Firebug uses nsIAnnotationService.

Here is the call stack:

file:///C:/Program%20Files/Mozilla%20Firefox%203.5RC1/components/nsLivemarkService.js (609)
file:///C:/Program%20Files/Mozilla%20Firefox%203.5RC1/components/nsLivemarkService.js (910)
null (0)
file:///C:/Program%20Files/Mozilla%20Firefox%203.5RC1/components/nsLivemarkService.js (949)
null (0)
file:///C:/Program%20Files/Mozilla%20Firefox%203.5RC1/components/FeedProcessor.js (1407)
file:///C:/Program%20Files/Mozilla%20Firefox%203.5RC1/components/FeedProcessor.js (1480)
null (0)
file:///C:/Program%20Files/Mozilla%20Firefox%203.5RC1/components/FeedProcessor.js (1446)
null (0)
file:///C:/Program%20Files/Mozilla%20Firefox%203.5RC1/components/nsLivemarkService.js (1008)

So deleteLivemarkChildren is failing with error 2147500033. The exception is gobbled up in the try block around line 1008 in nsLivemarkService. As a side effect, this._setResourceTTL() will not be recomputed. 

After about 20 of these, I kill the process. Over the period of a couple of weeks the number of these exceptions has grown. Since our code has changed, I can't say if the 100% CPU is part of the problem or only a side effect.

I have to find a workaround since I can't develop Firebug under this circumstance.
I added the line:
if (aFolderId)
just above line 609 and I did not get the message the next time.

I am running:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1) Gecko/20090616 Firefox/3.5

It is possible that this only occurs with Chromebug running.
Whiteboard: [firebug-p1]
(In reply to comment #1)
> I added the line:
> if (aFolderId)
> just above line 609 and I did not get the message the next time.

Wrong: I accidentally erased first character in the file. The error did not occur because the nsLivemarkService.js file did not compile.
The message does not depend upon Firebug becoming active. 

I copied the Firefox profile and in the original profile I deleted all the folder contents. Then I ran FF once, copied the extension directory contents from the old copy into the new version, ran again and exited. Now when I run I do not get the error message. I also do not get the message from modules/utils.js that I got before and posted on the newsgroup:


The lines:
    get livemarks() {
123 delete this.livemarks;
124 return this.livemarks =
             Cc["@mozilla.org/browser/livemark-service;2"].
125 getService(Ci.nsILivemarkService);
126 },

Gives a numerical error message at line 125.
The call stack points back to browser.xul:1191
 setTimeout(function() PlacesUtils.livemarks.start(), 5000);

So for now the workaround is "create a new profile".
Whiteboard: [firebug-p1] → [firebug-p3]
Similar to bug 479127?
After a few days the problem came back.
nserror says this is NS_ERROR_NOT_IMPLEMENTED, fwiw. I tried playing connect the dots for a while, but I am too tired. Try catching it in a debugger instead. Much more useful.
I am able to work around this problem by hacking nsLivemarkService.js to change:

  deleteLivemarkChildren: function LS_deleteLivemarkChildren(aFolderId) {
    return;
    this._bms.removeFolderChildren(aFolderId);
  },
could you please check if the patch in bug 481437 solves this for you?
I'm not sure who you are asking, but the problem continues for me and results in minute long pauses of 100% CPU.
yeah, John, was aking to you about current mozilla-central status regarding this bug.
Did anyone actually try my suggestion in comment #6? It'd be helpful to know where this is coming from.
(In reply to comment #11)
> yeah, John, was aking to you about current mozilla-central status regarding
> this bug.

Marco I see this bug is on 3.5.2 and I can't build mozilla-central now. But I'm unclear on what you would like me to do.
(In reply to comment #13)
> (In reply to comment #11)
> > yeah, John, was aking to you about current mozilla-central status regarding
> > this bug.
> 
> Marco I see this bug is on 3.5.2 and I can't build mozilla-central now. But I'm
> unclear on what you would like me to do.

Grab a nightly off FTP and check? If this is 100% reproducible for you, should be easy to do...
On
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a1pre) Gecko/20091001 Minefield/3.7a1pre
I get
"uncaught exception: 2147500033"
file:///C:/mozilla/firefox-3.7a1pre.en-US.win32/firefox/modules/utils.js
line
128

I've seen this on FF 3.5 every time I run for some months.
(In reply to comment #15)
> On
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a1pre) Gecko/20091001
> Minefield/3.7a1pre
> I get
> "uncaught exception: 2147500033"
> file:///C:/mozilla/firefox-3.7a1pre.en-US.win32/firefox/modules/utils.js
> line
> 128

When? Doing what? In Safe Mode? Dependent on which extensions? What about a clean profile? Does it depend on certain Firebug prefs? Exact STR on a clean profile would help, a lot, if you can't catch this in a debugger yourself.
I re-read the bug report from the beginning: there are two different errors both with the same obscure message 2147500033. The one reported to utils.js happens on startup  The real nasty ones are in nsLivemarkService.js, they are random times later, and they are the one that this bug report is about. I gave the call stack for those errors in the original post.

I think what is happening here is that a service that runs on a time interval is failing but the error is masked by the catch block. Maybe it does not matter to anyone else, since you can't see the problem unless you watch jsd.onError like I do. For everyone else is just a CPU hiccup.
(In reply to comment #17)
> Maybe it does not matter
> to anyone else, since you can't see the problem unless you watch jsd.onError
> like I do. For everyone else is just a CPU hiccup.

Huh? How is it an "uncaught" exception if there's a catch block? :-\
I have theory now for the CPU hit: according to 
http://mxr.mozilla.org/mozilla-central/source/toolkit/components/places/src/nsLivemarkService.js
the service by default checks one feed every second. So this spreads out the pain: if each feed throws an error and it takes a second to process the error, then the next on comes. It feels more like 3 seconds tho.
I set a breakpoint on line 609 of nsLivemarkService.js, 
   this._bms.removeFolderChildren(aFolderId);
After a while, the break point hits. Then I single step. I end up on like 6772 of browser.js.

     QueryInterface: function PSB_QueryInterface(aIID) {
6772 if (aIID.equals(Ci.nsINavBookmarkObserver) ||
6773 aIID.equals(Ci.nsISupports))
6774 return this;
6775
6776 throw Cr.NS_NOINTERFACE;
6777 }, 

where aIID is the number for this interface:

http://www.oxymoronical.com/experiments/apidocs/interface/nsINavBookmarkObserver_MOZILLA_1_9_1_ADDITIONS

So I guess that what is happening is PlacesStarButton is observing bookmarks but it does not support the interface for watching removal, so the removal operation throws. 

This is all based on JS debugging with chromebug where we don't really know what we can trust. Let's look on the C++ side.
It throwing that there is no interface is fine.  The c++ tries to QI to it, and if it fails, it won't notify about it.
(In reply to comment #20)
> I set a breakpoint on line 609 of nsLivemarkService.js, 
>    this._bms.removeFolderChildren(aFolderId);
> After a while, the break point hits. Then I single step. I end up on like 6772
> of browser.js.
> 
>      QueryInterface: function PSB_QueryInterface(aIID) {
> 6772 if (aIID.equals(Ci.nsINavBookmarkObserver) ||
> 6773 aIID.equals(Ci.nsISupports))
> 6774 return this;
> 6775
> 6776 throw Cr.NS_NOINTERFACE;
> 6777 }, 
> 
> where aIID is the number for this interface:
> 
> http://www.oxymoronical.com/experiments/apidocs/interface/nsINavBookmarkObserver_MOZILLA_1_9_1_ADDITIONS
> 
> So I guess that what is happening is PlacesStarButton is observing bookmarks
> but it does not support the interface for watching removal, so the removal
> operation throws. 
> 
> This is all based on JS debugging with chromebug where we don't really know
> what we can trust. Let's look on the C++ side.


NS_NOINTERFACE != NS_ERROR_NOT_IMPLEMENTED, to my knowledge. So, as far as I can tell, you're looking at the wrong thing.

I am still confused about comment #17. How come you're seeing an "uncaught exception" from something that's gobbled up by a catch block? If it's intended to be gobbled up by the try catch block, I am pretty sure this bug is INVALID, as Shawn somewhat implied.
On the C++ side we learn (I think) why the exception is "uncaught" and unreported, a long novel that starts:
// XXX We have a problem with error reports from uncaught exceptions.

http://mxr.mozilla.org/mozilla-central/source/js/src/xpconnect/src/xpcwrappedjsclass.cpp#859

So part of the bug here is that jsd.onError gets called at all. The onError function that will be called is a dummy, no-op, at this line:
>	js3250.dll!js_ReportErrorAgain(JSContext *, const char *, JSErrorReport *)  Line 1652	C++

So let me say this another way: the error cannot be posted to the error console because we don't yet know if it is uncaught. But it is posted to onError() which is incorrect, because we don't yet know if it is uncaught. (never mind that we have no way to know if it is uncaught, that is a different bug).
Well, then this doesn't sound like it's a places bug at all.
Component: Places → JavaScript Debugging APIs
Product: Firefox → Core
QA Contact: places → jsd
Version: 3.5 Branch → unspecified
(In reply to comment #22)
...
> NS_NOINTERFACE != NS_ERROR_NOT_IMPLEMENTED, to my knowledge. So, as far as I
> can tell, you're looking at the wrong thing.
...

I guess you are saying that 2147500033 == NS_ERROR_NOT_IMPLEMENTED where as
NS_NOINTERFACE == 2147500034?
I'm puzzle by this as well. The C++ call stack has QI:
 	xpc3250.dll!nsXPCWrappedJSClass::CallQueryInterfaceOnJSObject(XPCCallContext &, JSObject *, const nsID &)  Line 371	C++
so I think I am looking at the same thing I saw in the JS debugger
but I don't know what else it can a
http://mxr.mozilla.org/mozilla-central/source/toolkit/components/places/src/nsLivemarkService.js#117

browser.bookmarks.livemark_refresh_seconds int pref can  be set to change the refresh frequency. I guess setting it to a large number will make this happen less.

browser.bookmarks.livemark_refresh_delay_time int pref
can be set to a large number.

It looks like these have to be set then exit FF and restart to take effect.
you can try calling stopUpdateLivemarks() but notice you'll stop all livemarks updates for browser.
Blocks: 435025
See also Bug 526709, where I figured out why a similar exception occurs.
Status: NEW → RESOLVED
Closed: 15 years ago
Component: JavaScript Debugging APIs → RSS Discovery and Preview
Product: Core → Firefox
QA Contact: jsd → rss.preview
Resolution: --- → DUPLICATE
Version: unspecified → 3.5 Branch
Product: Firefox → Firefox Graveyard
You need to log in before you can comment on or make changes to this bug.