305001 - assertion when loading an install.rdf with a blank maxVersion or minVersion

Status: RESOLVED INCOMPLETE

(Core Graveyard :: RDF, defect)

Description

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I attempted to make assertions fatal on the balsa tinderbox, but it turned out
that one of the tinderbox scripts was overriding me.  That's fixed now.

In any case, there's a new assertion in the log as of yesterday.  The checkin
window is:
http://tinderbox.mozilla.org/bonsai/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=1124219460&maxdate=1124247539

The assertion (followed by the exception it throws) is:
  ###!!! ASSERTION: null ptr: 'aTarget != nsnull', file /builds/tinderbox/Firef
ox-gcc3.4/Linux_2.4.7-10_Depend/mozilla/rdf/base/src/nsInMemoryDataSource.cpp,
line 1385
  Break: at file /builds/tinderbox/Firefox-gcc3.4/Linux_2.4.7-10_Depend/mozilla
/rdf/base/src/nsInMemoryDataSource.cpp, line 1385
  *** ExtensionManager:_finishOperations - failure, catching exception - lineno
: 5934 - file: undefined - [Exception... "Component returned failure code: 0x80
004003 (NS_ERROR_INVALID_POINTER) [nsIRDFDataSource.Assert]"  nsresult: "0x8000
4003 (NS_ERROR_INVALID_POINTER)"  location: "JS frame :: file:///builds/tinderb
ox/Firefox-gcc3.4/Linux_2.4.7-10_Depend/mozilla/obj/dist/bin/components/nsExten
sionManager.js :: anonymous :: line 5934"  data: no]


balsa tinderbox should be orange until this is fixed

Comment 1

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I assigned to bsmedberg because the only checkin that seems at all related,
although not all that related, I'd have thought, is:

Bug 304476 (and 304478) - remove app.extensions.version from default prefs -
r=chase 

Comment 2

[Benjamin Smedberg]

I cannot reproduce the assertion in a local build. Is balsa using a clean
profile for this test? Is talkback being built? Any other non-default settings?

Comment 3

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

This went away with a clean profile.  (The console.log stuff actually means that
a Firefox tinderbox no longer can create a new profile without $CleanProfile=1.)

Comment 4

[Benjamin Smedberg]

It would be nice to know how this actually happened, but I'm going to mark
WORKSFORME until/unless steps to reproduce appear.

Comment 5

[:Gavin Sharp [email: [e-mail]]]

This was likely caused by one of the install.rdf changes:
http://tinderbox.mozilla.org/bonsai/cvsquery.cgi?file=%5C.rdf&filetype=regexp&date=explicit&mindate=2005-08-16+12%3A27&maxdate=2005-08-16+12%3A28

If I change the install.rdf in extensions/inspector to have empty maxVersion or minVersion fields (e.g. <em:minVersion></em:minVersion>), and rebuild in extensions/inspector, I get this assertion at startup. I can't reproduce more than once without rebuilding, so I'm assuming that you need to change the mtime on the dist/bin/extensions/inspector.mozilla.org/ directory for it's install.rdf to be re-read. The same issue was seen on balsa when bug 267789 landed.

If one of the @XXXX_VERSION@ values were somehow undefined during those builds, then the install.rdfs would have had blank (max|min)Versions, and this assertion would trigger.

Comment 6

[Sebastian Redl]

The same assertion occurs again on the Mercurial tree. It can be tracked back to nsExtensionManager.addItemMetadata, parsing the install.rdf for the DOM inspector, which has empty em:maxVersion elements for various applications.

Comment 7

[Florian Quèze [:florian]]

Attachment: JS Stack

I can reproduce if I have an install.rdf file with an empty minVersion for the default theme.

I'm attaching a JS Stack.

In my current build, nsExtensionManager.js:7648 is one of these lines:
        this._inner.Assert(anon, idRes, installManifest.GetTarget(newVersionInfo, idRes, true), true);
        this._inner.Assert(anon, minVersionRes, installManifest.GetTarget(newVersionInfo, minVersionRes, true), true);
        this._inner.Assert(anon, maxVersionRes, installManifest.GetTarget(newVersionInfo, maxVersionRes, true), true);