126421 - Assertion failure in reg.c:1538, plugin related?

Status: VERIFIED FIXED

(Core Graveyard :: Plug-ins, defect)

Description

[Erland Lewin]

Now and then for the last couple of days, I've been getting the following
assertion from Mozilla (recent cvs version):

Assertion failure: (offset < reg->hdr.avail), at reg.c:1538

Attaching a gdb stack trace. It seems to happen in plugin handling code.
I havn't been able to associate with any particular URL or action in the
browser.

Comment 1

[Erland Lewin]

Attachment: Stack trace of assertion

Added gdb stack trace of assertion.

Comment 2

[serge (gone)]

It looks like ~/.mozilla/appreg is corrupted.
--> [e-mail]

Comment 3

[Daniel Veditz [:dveditz]]

We probably crashed before all the updates were flushed out. You're pretty much
hosed now.

- the list of profiles should never have been locked up in an uneditable binary
format -- if it gets corrupted there's nothing you can do, and with the
directory name salting you'd never be able to fool us into pointing back at your
original directory.

- plugins should have stored their data in their own file, or they should flush
after they update their cache.

- now that the component registry is not going to be stored in this format I
could remove write caching and always hit the disk directly. That'd still slow
things down a bit, though.

Comment 4

[Erland Lewin]

Confirming that this happens deterministically when I do Help... About plugins.

I tried to install the Shockwave plugin recently, but failed (see bug #124815
and related bug #91470). I guess this might be what caused the corrupt appreg. 
  Note also that this is something which the average user might very well do
(try to install shockwave or other Netscape 4-plugin), and therefore that this
problem is not rare, but should be important to fix.

Is there a work-around? Can I remove the appreg file? What will I lose?

Also note that the crashes that this causes are quite frequent, I now have to
restart Mozilla often.

Comment 5

[Daniel Veditz [:dveditz]]

How handy are you with a binary editor?

What you will lose is your list of profiles. Because of the ugly "salting" in
profile directory names you will not be able to re-create exactly the same
profile directory, and because part of that salted name is embedded in various
profile files you can't just copy your existing files to the new directory. 
After deleting the file and re-creating a profile or profiles with the same name
(but not salted directory) you could edit the "salt" part of the path in the
appreg file to point at your old directory.

Back to plugins, they should fix their code. Crashes happen, take steps to fail
safe by flushing data to disk.

Comment 6

[Peter Lubczynski]

nominating nsbeta1

Comment 7

[Erland Lewin]

Attachment: Proposed patch: nr_FindAtLevel fails with error instead of assert

This is my first patch submission to Mozilla; please let me know if I'm doing
anything wrong...
  I would like a review for this patch.

The patch replaces the assertion which caused the crash with an if clause,
causing the nr_FindAtLevel function in reg.c to return an error (REGERR_FAIL)
instead of a crashing assert.
  IMHO situations such as corrupted files which can happen should be handled /
recovered from rather than checked by assert, and I therefore think that this
is a good fix.
  I can't judge if a new REGERR_ code should be returned here
(REGERR_CORRUPT_FILE?) rather than REGERR_FAIL.
  The patch fixed the crashes I was experiencing, I can for instance bring up
the "About Plugins" dialog.

Of course, this fixes a symptom of the corrupted registry, I can't tell if
there are any better high-level ways to cope with this situation.

Comment 8

[Winnie Lam]

minusing to nsbeta1- as per ADT triage.  it may just be the person's corrupted
registry.  not strictly plug-ins bug.

Comment 9

[Jungshik Shin]

Attachment: full stack trace with local variables

Attached is the full stack trace with local variables
I obtained from gdb when Mozilla made an assertion
in reg.c and killed itself.  Plug-in related calls
are made from JVMManager in my case.

Very strange is that this happens only with my own
debug build (with the source updated around 3am 
Pacific time) while 0.9.9 and 2002-03-25-06 don't
have this problem. This appears to indicate 
that appreg file cannot be at fault. If it is,
that should affect all versions, shouldn't it?

Because this happens only with my debug build, I guess
I may not regard it as a genuine bug
(I can't test my patches that I'm sure are totaly unrelated
to this due to this problem), 
but it would be nice if you could take a look at the stacktrace and see
what's going on.
 
I built my debug build under RH 7.1 with gcc 2.96(unofficial
RedHat patched version) and glibc 2.2.4(-19.3), gtk+-1.2.9(-4).

Comment 10

[Jungshik Shin]

I'm not sure why only my own build had this trouble, but
backing up old profile directory, removing appreg,
running mozilla again to create a profile and restoring
backed-up profile directory solved the problem for me. 
Now both builds made at mozilla.org and my own work well.

Comment 11

[rubydoo123]

marking as fixed based on comment #10

Comment 12

[shrirang khanzode]

.