Starting up with -P (profile manager), selecting a profile, and starting hits "Assertion failure: !JSRuntime::hasLiveRuntimes() (forgot to destroy a runtime before shutting down)"

NEW
Assigned to

Status

()

--
critical
5 years ago
4 months ago

People

(Reporter: Waldo, Assigned: Waldo)

Tracking

({assertion})

Firefox Tracking Flags

(Not tracked)

Details

(Assignee)

Description

5 years ago
The assertion is because we're not destroying all JSRuntimes before calling JS_ShutDown, which means that someone's leaking basically all the JS in existence.
I started investigating the profile manager shutdown leaks in bug 732493, but it didn't really seem like a good use of time.  There wasn't that much leaking, but it wasn't cycle collected, so it involved repeated rounds of refcount logging, which was tedious.
(Assignee)

Comment 2

5 years ago
bsmedberg's long wanted to just remove the profile manager UI, which would solve this.

The assertion got weakened/removed into a fprintf(stderr, ...), so of course at this point nobody will care any more anyway.
(In reply to Jeff Walden [:Waldo] (remove +bmo to email) from comment #2)
> bsmedberg's long wanted to just remove the profile manager UI, which would
> solve this.

True, but I'm pretty sure he was not suggesting to 'just' remove it, but rather think of something smart to replace the Profile Manager that is less obtrusive, more intuitive to use, etc. Not a 'light' project per sé ;)

> The assertion got weakened/removed into a fprintf(stderr, ...), so of course
> at this point nobody will care any more anyway.

That makes me smile and cry at the same time: smile, because the immediate problem is resolved and cry, because a MOZ_ASSERT is the right thing to have in an 'independent' component like SM... but can't because of stuff.
As long as absolute modularity and functional compartments are not a reality, we'll need a migration paths to resolve cross-dependencies. We'll get there, eventually!
(Assignee)

Comment 4

5 years ago
(In reply to Mike de Boer [:mikedeboer] from comment #3)
> True, but I'm pretty sure he was not suggesting to 'just' remove it, but
> rather think of something smart to replace the Profile Manager that is less
> obtrusive, more intuitive to use, etc. Not a 'light' project per sé ;)

Actually, I don't think he was.  Given that -profile works and is much nicer (you don't have to go through a wizard to create a profile, it just gets created/used in the directory you specify), I think that was the entire replacement.  Profilers are already a developer/power feature, so lack of non-commandline UI for them shouldn't really be a problem (we already recommend -P foo in tons of docs, so we already assume this).  I'll let him correct me if I misunderstood, tho.

Comment 5

5 years ago
I think this bug should be INCOMPLETE; it's just not worth the effort. The other bug is bug 214675.

Updated

2 years ago
See Also: → bug 1303637
You need to log in before you can comment on or make changes to this bug.