SeaMonkey Mail crash on startup

[barbaz]

SeaMonkey 2.30 (not what you see below)
Linux x86_64

On some boots of my computer, SeaMonkey mail crashes on every startup, and the only solution I've found so far is rebooting the OS. Seems to be triggered when I don't log in the OS login screen right away, but it seems not the only factor.

SeaMonkey browser, which I'm using to post this, works fine and is unaffected.

What I've tried:
- Different versions of SeaMonkey (works at first, but eventually same result on a different boot)
- Safe Mode (can get to the "Continue in Safe Mode" screen, but after that it still crashes)
- Starting in the Profile Manager first

This being a Mail profile containing POP accounts, I'm not sure how to safely try the whole new profile deal without risking data loss.

How best to find and get rid of this crash problem?

[DanRaisch]

Creating a new profile will not touch the message data stored in the old profile. Create a new one and add the email account, test to see if there are still crashes. If not, you can migrate the message data data from the old profile.

Be sure to backup before doing anything else and in the settings for the new POP account, be sure to set "Leave messages on server." That way when you bring over the data from the other account you can include the file popstate.dat which should result in the download of any messages that download to the new one, avoiding loss or duplication.

[barbaz]

Thanks, tried a clean profile now. But it crashes on startup there too

EDIT OK, based on this, I deleted the entire seamonkey folder and re-extracted the same build's tarball to the same place. Now it's working again.
What is going on here?

More detailed OS info:

Code: Select all

$ uname -a
Linux xxxxxx 3.13.0-96-generic #143-Ubuntu SMP Mon Aug 29 20:15:20 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 14.04.5 LTS
Release:        14.04
Codename:       trusty

Code: Select all

System:    Kernel: 3.13.0-96-generic x86_64 (64 bit, gcc: 4.8.4) 
           Desktop: LXDE (Openbox 3.5.2) dm: lightdm Distro: Ubuntu 14.04 trusty

[therube]

Did you backup the old, & do a diff, old vs new?
Maybe a (needed) file got deleted, or a file corrupted?

[barbaz]

Did you backup the old, & do a diff, old vs new?

Oops, no, I just straight deleted it without thinking. Shift+Del,Enter is becoming too automatic.

Oh well, this will probably happen again. I'll make a point to save the old seamonkey folder next time.

[barbaz]

I just hit the same issue again, but with SeaMonkey browser this time.

Code: Select all

$ diff -r ******/seamonkey-crapod ******/seamonkey 
Binary files ******/seamonkey-crapod/libxul.so and ******/seamonkey/libxul.so differ

Thanks therube, looks like you nailed it.

Now, question is, why would that file get corrupted? AFAIK I didn't even access it outside the sandbox between when this worked and when not.

[therube]

Is libxul.so akin to xul.dll (~50 MB) ?
And this is in your instalDir?

And this instalDir should be "static"?
As in this is not a directory that you've updated, messed with different versions ... none of that.
You simply installed once & run using that (particular) install.
Nothing should be messing with anything in that directory.

Now you might have different installs, different versions, elsewhere, but this one is intended to be "2.46" & nothing more.

If that's the case, there is no reason for anything "Mozilla" nor anything outside of Mozilla to be messing with anything within that instalDir.


So... an ailing disk?
Might have a spot going bad.
Old install & the "good" reinstall happened to end up around the same physical spot on disk.
Maybe bad spot grew "just enough", happened to corrupt libxul.so ...

Do a binary diff on libxul.so.
Maybe that will point something out. Like a section of nulls where you would think them to be unexpected.
http://superuser.com/questions/125376/h ... s-in-linux

(Sometimes, a "text mode" diff on a binary file works better then "binary mode", in particular if a file has a "header", like mp3 music tag, where the header part might differ, but where the "music" part is the same, binary will find the first diffs, & try to go from there, not realizing that what it found was simply a "tag", so it ends up saying the whole file is different, where a "text" diff might catch only the tag diffs, & realize that the rest of the file is the same - kind of thing. Probably wouldn't apply here, but can't hurt to try...)

Or possibly memory corruption, http://www.memtest86.com/?

[barbaz]

Is libxul.so akin to xul.dll (~50 MB) ?
And this is in your instalDir?

And this instalDir should be "static"?

I don't know the install files on Windows, but .so's are indeed the Linux equivalent of .dll's.
Yes it's my install dir.

I did upgrade from 2.46pre to 2.46 a few days ago, but AFAIK it had been untouched since then.

Do a binary diff on libxul.so.
Maybe that will point something out. Like a section of nulls where you would think them to be unexpected.

Used xxd like

Code: Select all

xxd libxul.so > libxul.so.dump

Then did the diff -

Code: Select all

diff -r ******/seamonkey-crapod/libxul.so.dump ******/seamonkey/libxul.so.dump
2500235,2500243c2500235,2500243
< 26268a0: ef23 48c1 ea03 4c8b 8898 0100 5300 0000  .#H...L.....S...
< 26268b0: 0000 0700 00b2 afb0 8000 0000 0000 0601  ................
< 26268c0: 5006 0f00 89fa d3ea 89d0 488d 0440 498d  P.........H..@I.
< 26268d0: 34c1 0a04 6802 96cb 4010 0000 ffff ffff  4...h...@.......
< 26268e0: ffff a4ee 5718 a855 ffff ffff ffff f0fa  ....W..U........
< 26268f0: 0000 0108 0204 0b0c 1216 1824 0301 012d  ...........$...-
< 2626900: 1a62 0100 ff00 0000 0100 0000 0000 0000  .b..............
< 2626910: 0000 0000 0000 0000 0000 0032 0430 4860  ...........2.0H`
< 2626920: 6c5b b156 21e4 0000 0044 29c2 21ca 89d0  l[.V!....D).!...
---
> 26268a0: ef23 48c1 ea03 4c8b 8898 0100 0031 fa69  .#H...L......1.i
> 26268b0: d2b9 7937 9e44 89d1 8d7a fe83 fa01 0f47  ..y7.D...z.....G
> 26268c0: fa83 e7fe 89fa d3ea 89d0 488d 0440 498d  ..........H..@I.
> 26268d0: 34c1 8b06 85c0 0f84 7c00 0000 89c1 83e1  4.......|.......
> 26268e0: fe39 cf0f 8415 0100 0041 0fb6 ca41 bb20  .9.......A...A. 
> 26268f0: 0000 0041 89f8 4129 cb44 89d9 41d3 e044  ...A..A).D..A..D
> 2626900: 89d1 41ba 0100 0000 41d3 e844 89d9 41d3  ..A.....A..D..A.
> 2626910: e241 83c8 0141 8d4a ff45 31d2 0f1f 4000  .A...A.J.E1...@.
> 2626920: 83f8 010f 84e4 0000 0044 29c2 21ca 89d0  .........D).!...

Not sure what that means.

This is a self build SeaMonkey, so there's no comparison to the official builds.

So... an ailing disk?

Maybe, but wouldn't it be pretty odd that this only ever happens to SeaMonkey? And that a reboot would have any effect?

Or possibly memory corruption, http://www.memtest86.com/?

That's possible..

I have Apple hardware. Because of this, memtest86 (which comes preinstalled in *buntu) is automatically disabled by the bootloader.

[barbaz]

Did a reboot. Extracted the seamonkey tarball someplace else, just to make really sure. Repeated the diffs.

Code: Select all

$ diff -r ******/seamonkey-crapod ******/seamonkey 
Only in seamonkey-crapod: libxul.so.dump

Notice how libxul.so is now identical.

The diff of the old hexdump & the new one (of the same libxul.so file, after reboot) is identical to what I posted before.

[therube]

(I'm a bit confused, but...)

So after reboot, crapod/libxul.so == seamonkey/libxul.so
A diff shows them to be the same.

But an xxd of crapod/libxul.so still does not compare to seamonkey/libxul.so ?
How can that be?

Does diff specifically need --binary when dealing with binary files?
No.

Something with your VM?
If you do this outside the VM?

[barbaz]

Sorry, my point was, the libxul.so file itself really does seem to have changed completely back to normal.

Something with your VM?
If you do this outside the VM?

None of this is inside a VM. All of it is on my primary, bare-metal OS. I have not seen this issue inside a VM.

EDIT Oh, I see why you're referring to VMs. When I first noticed this problem, I wasn't running SeaMonkey mail inside a sandbox (firejail).

[barbaz]

... and yet again hit this issue with SeaMonkey browser. And again, it's a corrupted libxul.so.

But the diff this time is different -

Code: Select all

$ diff seamonkey-crapod/libxul.so2.dump seamonkey/libxul.so.dump
2411147,2411155c2411147,2411155
< 24ca8a0: 4dd0 ff48 8b54 2410 488b 0424 4889 5368  M..H.T$.H..$H.Sh
< 24ca8b0: 488b 5424 1848 8943 5848 8b44 2408 4889  H.T$.H.CXH.D$.H.
< 24ca8c0: 5370 488b 5424 2083 f808 4889 4360 4889  SpH.T$ ...H.C`H.
< 24ca8d0: 5378 488b 5424 2848 8993 8000 0000 741e  SxH.T$(H......t.
< 24ca8e0: 83f8 0176 1983 f804 0f84 5cff ffff 4c89  ...v......\...L.
< 24ca8f0: efe8 da4f d0ff 8b43 6083 f808 75e2 83f8  ...O...C`...u...
< 24ca900: 040f 8443 ffff ff48 89df e811 e1ff ffc7  ...C...H........
< 24ca910: 4318 0200 0000 e9a0 0000 000f 1f44 0000  C............D..
< 24ca920: 488b 7350 4c89 f7e8 f4b4 1c00 488b 0424  H.sPL.......H..$
---
> 24ca8a0: 4dd0 ff48 8b54 2410 488b 0424 5300 0000  M..H.T$.H..$S...
> 24ca8b0: 0000 0700 00ab afaf 8000 0000 0000 0601  ................
> 24ca8c0: a093 0f00 5424 2083 f808 4889 4360 4889  ....T$ ...H.C`H.
> 24ca8d0: 5378 0a04 6802 96cb 4010 0000 ffff ffff  Sx..h...@.......
> 24ca8e0: ffff a4ee 5718 a855 ffff ffff ffff b08b  ....W..U........
> 24ca8f0: 0000 0108 0204 0b0c 1216 1824 0301 012d  ...........$...-
> 24ca900: 1a62 0100 ff00 0000 0100 0000 0000 0000  .b..............
> 24ca910: 0000 0000 0000 0000 0000 0032 0430 4860  ...........2.0H`
> 24ca920: 6cd5 b070 3889 f7e8 f4b4 1c00 488b 0424  l..p8.......H..$

"seamonkey-crapod" is the same, now-good install dir as before. "seamonkey" is the one that got corrupted.

[frg]

Did you check the SMART settings of your disk?

FRG

[barbaz]

It says "Disk is OK".

[frg]

If you don't have ECC ram I would also check it. And might also just be a faulty driver. Anything about CRC errors in the SMART log? disk might still show up ok even with them.

FRG