228263 - crash when typing something in the 'Name or E-mail contains' text field of the address book

Status: RESOLVED WORKSFORME

(SeaMonkey :: General, defect)

Description

[Thomas Claveirole]

User-Agent:       Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.5) Gecko/20031118
Build Identifier: Mozilla/5.0 (X11; U; IRIX IP32; en-US; rv:1.5) Gecko/20031205

I  have compiled mozilla  1.5 using  gcc 2.95  on an  IRIX 6.5  OS. It
mostly works well, but when I  launch the address book and try to type
anything in the 'Name or E-mail contains' field, it exits with code 11.

To be more precise, the first time I run mozilla after I have compiled
it, everything is  ok and I cannot reproduce the  bug. However, when I
close mozilla and  launch it again, the problem appears.  If I set the
installed files and directories read-only,  the bug does not appear. I
ran  a diff -dur  between a  healthy directory  and another  which was
buggy. Here is what I obtain:

$ diff -dur mozilla-1.5.ok mozilla-1.5
Only in mozilla-1.5/lib/mozilla-1.5/chrome: chrome.rdf
Only in mozilla-1.5/lib/mozilla-1.5/chrome: overlayinfo
Only in mozilla-1.5/lib/mozilla-1.5/components: compreg.dat
Only in mozilla-1.5/lib/mozilla-1.5/components: xpti.dat

Reproducible: Always

Steps to Reproduce:
1. Compile and install mozilla on a IRIX 6.5 system (compiled using gcc 2.95).
2. Launch it, open the address book, type some text in the 'Name or E-mail
contains' Field.
3. Close mozilla.
4. Re-do step 2.

Actual Results:  
Mozilla exits with code 11.

Expected Results:  
Searched my address book for entries which match what I have typed :)

Here are the options I passed to configure:
  --disable-debug
  --enable-optimize
  --enable-calendar
  --enable-crypto

I will attach the 4 files revealed by the diff (see Details).

Comment 1

[Thomas Claveirole]

Attachment: Files created during the first run of Mozilla.

See the bug report for explanations about this file

Comment 2

[Jon Henry]

Is there any way you could do a debug build (just remove the --disable-debug and
--enable-optimize from your .mozconfig) and then reproduce the crash under a
debugger? Having a stack trace would let us at least assign this to the right
component, and hopefully narrow down a fix.

Comment 3

[Thomas Claveirole]

I have already tried to get a stack trace, without success.

Compilation without --disable-debug and --enable-optimize is ok, but
unfortunately I am running an old o2 which has 256 Mb RAM and something like a
266 Mhz processsor. After running mozilla inside a debugger for more than a
night without having even a window opening, I gave up.

Maybe I can compile it with debug enabled and upload the result somewhere so you
can reproduce the bug with a debugger and and a more powerfull machine ?

Comment 4

[Jon Henry]

Unfortunately I don't have access to anything running IRIX or SunOS, but perhaps
someone else would be able to work with you on that.

Comment 5

[Thomas Claveirole]

Apparently this bug is related to the file components/compreg.dat. If I remove
it before launching mozilla, the bug does not appear. This file seems to be
generated by mozilla when it is launched.

Comment 6

[Jon Henry]

Are you still seeing this bug in recent Mozilla builds? I think some work has
been done recently to help tolerate corrupt profiles, perhaps upgrading to a
recent nightly build could overcome this.

Comment 7

[Jon Henry]

Resolving WFM, since there is no response on whether or not the bug still
exists. Also possibly a dupe of bug 178243.