User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826 After a crash due to sidebar development, mozilla never starts. First of all, I have rename .mozilla directory to .mozilla_old. As a result, mozilla creates new profile and starts normally, but without my old profile. I've tried to understand what happens and after watching configuration file definitions : I have copied whole old profile without XUL.mfasl file. As a result, mozilla reworks with my whole old profile. Reproducible: Sometimes Steps to Reproduce: 1.Start mozilla 2.Crash during develop of sidebar 3.Restart mozilla Actual Results: Mozilla never starts Expected Results: Mozilla normally restarts After deleting XUL.mfasl file from profile, mozilla normally restarts.

1.1 is pretty old. please try a newer release (1.2b) or a nightly build. can you reproduce this? it would be nice to know what specifically triggered the crash/corruption.

Seems to be related (unfortunately not reproducible): Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20021016 Edit Preferences -> Privacy & Security -> Certificates -> Manage Certificates ... pressing the "import" button caused 100% CPU and mozilla hanging After killing and restarting it: ok, but: selecting edit -> preferences caused the same effect (100% CPU, hanging); several times, also after system restart replacing XUL.mfasl by a backup copy solved the problem -> XUL.mfasl must have been corrupted.

What does "system restart" in comment #2 mean? Can someone run a system call tracer on the hung mozilla-bin? How about attaching to it with gdb and getting a stack (or stacks, if it is indeed running and not hung without any thread making progress, e.g., deadlocked)? /be

Response for comment #1 Unfortunatly, I can't reproduce cause of my problem. This problem comes to me two times : with first crash, I don't known exactly why it became, but for second one, crash appeared when I want to show Sidebar. Moreover, I can reproduce "non starting" of mozilla with my corrupted XUL.mfasl file.

response to comment #3 "system restart" means eventually rebooting (I wanted to make sure that this is really a mozilla problem). I still have a backup copy of the damaged XUL.mfasl; strace results in: [...] read(10, "k\0e\0y\0m\0a\0s\0t\0e\0r\0/\0g\0a\0t\0e\0k\0e\0"..., 8192) = 8192 read(10, "\0\0\0A\0d\0d\0M\0o\0d\0u\0l\0e\0\0\0\2\0\0\0\0\0\0\0\t"..., 8192) = 8192 read(10, "\312`\r\264c\3g\n\264c\3g\n3\264c\3\312`\r\264c\3\312`"..., 8192) = 8192 read(10, "\0e\0n\0D\0B\0\0\0\5\0\0\0\4\0\0\0\n\0\0\0g\0e\0t\0S\0"..., 8192) = 8192 read(10, "\0\0n\0s\0I\0P\0K\0I\0P\0a\0r\0a\0m\0B\0l\0o\0c\0"..., 8192) = 8192 read(10, "e\0m\0e\0n\0t\0B\0y\0I\0d\0\7\0\0\0\4\0\0\0\23\0\0\0w\0"..., 8192) = 8192 read(10, "w\0\36\0\0\0\4\0\0\0\n\0\0\0o\0p\0e\0n\0D\0i\0a\0l\0o\0"..., 8192) = 8192 read(10, "l\0e\0d\0\0\0\0\0\0\0\5\0x\0m\0l\0n\0s\0\0\0\0\0\0\0\t"..., 8192) = 8192 read(10, "h\0e\0r\0e\0.\0i\0s\0.\0o\0n\0l\0y\0.\0x\0u\0l\0"..., 8192) = 8192 read(10, "\0i\0s\0.\0o\0n\0l\0y\0.\0x\0u\0l\0\0\0\6\0t\0a\0b"..., 8192) = 8192 read(10, "js\0\0\371v\0\0\0008chrome://messenger-smi"..., 8192) = 8192 read(10, "*chrome://messenger/content/acco"..., 8192) = 4337 read(10, "", 8192) = 0 munmap(0x41cc6000, 15077376) = 0 munmap(0x41a00000, 2908160) = 0 read(10, "", 8192) = 0 read(10, "", 8192) = 0 the last line is repeated endlessly. I'm not familiar with gdb and such, I hope this backtrace is the information you need (checked several times, always the same): #0 0x40522b55 in sigsuspend () from /lib/libc.so.6 #1 0x402186bf in __pthread_wait_for_restart_signal () from /lib/libpthread.so.0 #2 0x40214e8d in pthread_cond_wait () from /lib/libpthread.so.0 #3 0x401e0c49 in PR_WaitCondVar () from /opt/mozilla/libnspr4.so #4 0x4016c905 in nsThreadPool::GetRequest () from /opt/mozilla/libxpcom.so #5 0x4016cfbe in nsThreadPoolRunnable::Run () from /opt/mozilla/libxpcom.so #6 0x4016bcda in nsThread::Main () from /opt/mozilla/libxpcom.so #7 0x401e561e in PR_Select () from /opt/mozilla/libnspr4.so #8 0x40215e67 in pthread_start_thread () from /lib/libpthread.so.0 #9 0x40215eb5 in pthread_start_thread_event () from /lib/libpthread.so.0

This morning when I was going to check my mail, Mozilla (1.2 beta on Linux, build ID 2002101612) suddenly hung, using 100% CPU. The browser had been running for a couple of days. When I killed it and tried to restart it, it immediately hung again, using 100% CPU. An strace showed the following: [pid 27518] read(5, "\201\0\300\2", 4) = 4 [pid 27518] access("/home/jk/.mozilla/mozProfile/XUL.mfasl", F_OK) = 0 [pid 27518] open("/home/jk/.mozilla/mozProfile/XUL.mfasl", O_RDONLY|O_LARGEFILE) = 19 [pid 27518] read(19, "XPCOM\nMozFASL\r\n\32\267\326\376\257\0\0\0\3\0$j\325\0"..., 32) = 32 [pid 27518] lseek(19, 0, SEEK_END) = 2396122 [pid 27518] lseek(19, 0, SEEK_CUR) = 2396122 [pid 27518] read(19, "", 8192) = 0 [pid 27518] lseek(19, 2386645, SEEK_SET) = 2386645 [pid 27518] read(19, "\0\0\0\3\0\0\0\333\0\0\0\201\0\0\0\vJb\22\333\254\313\21"..., 8192) = 8192 [pid 27518] read(19, "://communicator/content/sidebar/"..., 8192) = 1285 [pid 27518] stat64("/usr/local/mozilla/chrome/venkman.jar", {st_mode=S_IFREG|0644, st_size=250468, ...}) = 0 ... ... lots of reading, sometimes lseek()ing ... ... [pid 27518] read(19, "\2367y\273\0\0\0\1\377\377\377\377\377\377\377\377\1\0"..., 8192) = 8192 [pid 27518] lseek(19, 0, SEEK_SET) = 0 [pid 27518] read(19, "XPCOM\nMozFASL\r\n\32\267\326\376\257\0\0\0\3\0$j\325\0"..., 8192) = 8192 [pid 27518] mmap2(NULL, 1873674240, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x42784000 [pid 27518] read(19, "\0\0\7\0000\205;\0\0005\0\0019;\0\2:\0\1\2l\0\0@m\0\0\2"..., 8192) = 8192 [pid 27518] read(19, "\0B\0u\0t\0t\0o\0n\0s\0\0\0\6\0\0\0\0\0\0\0\4\0\0\0\1\0"..., 8192) = 8192 [pid 27518] read(19, "9=\0\tB:\0\2m\0\7\2l\0\nV\0\0015\0\0109=\0\vB:\0\2m\0\n"..., 8192) = 8192 ... ... [pid 27518] read(19, "\271Zd\4\0\0\0\0\0\0\0\0\'\0\0\0chrome://messeng"..., 8192) = 8192 [pid 27518] read(19, "e\0R\0e\0c\0o\0r\0d\0\0\0\3\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 8192) = 8192 [pid 27518] read(19, "l\0u\0m\0n\0\220\0\0\0\260\260c\3\313`\3c\6\17\263\262"..., 8192) = 8192 [pid 27518] read(19, "\0n\0l\0y\0.\0x\0u\0l\0\0\0\7\0t\0e\0x\0t\0b\0o\0x"..., 8192) = 8192 [pid 27518] read(19, "c\0o\0n\0t\0a\0i\0n\0e\0r\0\0\0 \0\0\0\7\0?\0m\0e\0"..., 8192) = 8192 [pid 27518] read(19, "ontent/filepicker.xul\0\16\f-\0\0\0(chr"..., 8192) = 4058 [pid 27518] read(19, "", 8192) = 0 [pid 27518] munmap(0x42784000, 1873674240) = 0 [pid 27518] read(19, "", 8192) = 0 [pid 27518] read(19, "", 8192) = 0 ... Again, the last line was repeated indefinitely, with an occasional sprinkling of memory allocations and: [pid 27518] read(19, "", 8192) = 0 [pid 27518] read(19, <unfinished ...> [pid 27519] <... poll resumed> [{fd=8, events=POLLIN}], 1, 2000) = 0 [pid 27519] getppid( <unfinished ...> [pid 27518] <... read resumed> "", 8192) = 0 [pid 27519] <... getppid resumed> ) = 27518 [pid 27518] read(19, <unfinished ...> [pid 27519] poll( <unfinished ...> [pid 27518] <... read resumed> "", 8192) = 0 [pid 27518] read(19, "", 8192) = 0 When I removed XUL.mfasl, I could finally start Mozilla.

See bug 177986 comment 6: hope this helps.

The "reading forever" strace logs above, are the same as bug 169777. But before marking as a duplicate, does anyone still have a copy of the XUL.mfasl files that were causing this problem? If you do, could you either attach a gzipped copy of the XUL.mfasl to this bug, or just email it to <jrgm@netscape.com>. It helps if we can analyze what is incorrectly structured in the fastload file.

Attaching the XUL.mfasl file that caused my Mozilla to hang, as requested. I have not tested this with the current version of Mozilla.

Attaching part 2 of XUL.mfasl (had to be split due to Bugzilla attachment size limitations)

Reply to comment 8: JohnM, can you have a look at the corrupted file (comment 9 and 10), and make a statement on whether or not this bug is a dupicate ?

Interesting, mine was corrupted in a place where I could start and use the browser, but when the mail & news window was started it froze and exhibited the same behaviour as described above... Unfortunately it's happened to me twice now and I've just figured out what file to restore. I might be able to re-create the XUL.mfasl file but it takes a bit of work. I also have a trace, if someone is interested.

I should have mentioned that I'm running 1.2.1 on an x86 Linux machine.

This was fixed in 1.3b, and in 1.3. *** This bug has been marked as a duplicate of 169777 ***