MozillaZine


SeaMonkey 2.53.9b1pre Library crash

Discussion about Seamonkey builds
TPR75
 
Posts: 1111
Joined: July 25th, 2011, 8:11 am
Location: Poland

Post Posted May 17th, 2021, 1:59 pm

While using SeaMonkey 2.53.7.1 I've experienced a crash. It was during some cleaning of browsing history in Library. I've selected c.a. 250 entries and hit Del on keyboard. I knew I can expect something fancy so I was monitoring Task Manager and as expected "seamonkey.exe" process took entire core of Intel i5 CPU (25%) and it was swallowing RAM like mad. I've got 16 GB of RAM but "seamonkey.exe" took c.a. 14 GB and system (Windows 7 SP1 64-bit ESU) give warning that OS is running out of memory. First time I've hit "Cancel" but next time Windows 7 just gave me information and terminated "seamonkey.exe" process. Then SeaMonkey's Crash Reporter mad some work and there is crash report available:
https://crash-stats.mozilla.org/report/ ... bf90210517

Well, then why topic is about 2.53.9? Because I've tested few more times with latest SeaMonkey 2.53.9 (Build identifier: 20210516210002). With similar result:
1) TEST #1
I've copied my default profile to "TEST_CRASH" and made it run with 2.53.9 - the same situation with CPU-RAM-Crash:
https://crash-stats.mozilla.org/report/ ... 9bb0210517

2) TEST #2
I've notice that last time new module was involved "ebehmoni.dll". It's from ESET NOD32 AntiVirus (not present for 2.53.7.1 crash). I've made exception for entire folder with "seamonkey.exe" to not involve AntiVirus here... and crash the same like for TEST #1:
https://crash-stats.mozilla.org/report/ ... cd00210517

3) TEST #3
I've forgot about files in profile that can be checked by AV so I've made another exception for profile "TEST_CRASH" and... situation was a little bit different this time. Since TEST #2 cleared 250 entries so I choose more demanding case - over 17000 entries (daily news portal). RAM was not consumed up to 14 GB but after 3GB SeaMonkey offered "help" with running script:
Image

When this "offer" was displayed (usually "629" but sometimes "628") then RAM dropped form 3 GB to usual 600 MB but after "Continue" it raised to 3 GB again. I've pressed "Continue" button several times. I didn't wanted to wait very long for result so I've hit "Debug script" button and then SM reached 14 GB, OS terminated process and it crashed:
https://crash-stats.mozilla.org/report/ ... 3070210517

There is something about DLL from Nvidia drivers. I've got latest 466.27.

Can somebody confirm it's a bug not a feature?

It's a pity we can't have old history management system because it was more functional than present "Library". I understand why it happened. I just hope that memory leaking can be fixed. Someday.

frg
 
Posts: 1153
Joined: December 15th, 2015, 1:20 pm

Post Posted May 17th, 2021, 4:39 pm

It should not hit a GB or two with deleting 250 entries. I tested this a few times in the past. Unfortunately it seems the crash symbols are missing for 2.53.7.1. Need to look up the ones from the builder to see where it did go south. Not sure fi i manage soon.

TPR75
 
Posts: 1111
Joined: July 25th, 2011, 8:11 am
Location: Poland

Post Posted May 18th, 2021, 4:33 am

frg wrote:Need to look up the ones from the builder to see where it did go south.


It could be this bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1562490

frg
 
Posts: 1153
Joined: December 15th, 2015, 1:20 pm

Post Posted May 18th, 2021, 4:52 am

I can reproduce the stall when I delete a chunk of history via selectiong all and delete but not via the left tree selection. Seems uses different queries there.

Probably https://bugzilla.mozilla.org/show_bug.cgi?id=734643

There seem to be some fixes for Firefox 88 but not sure If I can backport them easy. I plan to remove the old synchronous api first for 2.53.9. The async one is the default now for a few releases and I doubt any old add-on has survived here anyway.

FRG

Frank Lion

User avatar
 
Posts: 21097
Joined: April 23rd, 2004, 6:59 pm
Location: ... The Exorcist....United Kingdom

Post Posted May 18th, 2021, 9:20 am

frg wrote:I can reproduce the stall when I delete a chunk of history via selectiong all and delete but not via the left tree selection. Seems uses different queries there.

In case it's useful as a workaround meanwhile...I get this with Places - chrome://communicator/content/places/places.xul but not when I use the History Sidebar (chrome://communicator/content/history/history-panel.xul)

With that History sidebar stuff deletes fine, including on a 'By Site' basis, when I must be deleting many thousands of entries when I delete anything (Search/Mail/Maps) Google on a monthly basis.
Metal Lion SeaMonkey Themes - Sea Monkey and Silver Sea Monkey
"The only thing necessary for the triumph of evil, is for good men to do nothing." - Edmund Burke (attrib.)

TPR75
 
Posts: 1111
Joined: July 25th, 2011, 8:11 am
Location: Poland

Post Posted May 18th, 2021, 10:09 am

Frank Lion wrote:With that History sidebar stuff deletes fine, including on a 'By Site' basis, when I must be deleting many thousands of entries when I delete anything (Search/Mail/Maps) Google on a monthly basis.


Well. Good thing is it didn't crashed but CPU was 25% (100% per core) and RAM over 13GB for few minutes. And I tried c.a. 200 entries only...

I've checked places.sqlite integrity and done compacting. This file isn't small (55 MB). Sorting is from latest (top view).

TPR75
 
Posts: 1111
Joined: July 25th, 2011, 8:11 am
Location: Poland

Post Posted May 23rd, 2021, 1:19 pm

Frank Lion wrote:With that History sidebar stuff deletes fine, including on a 'By Site' basis, when I must be deleting many thousands of entries when I delete anything (Search/Mail/Maps) Google on a monthly basis.


Unfortunately, more than 1000-1500 entries crashed SeaMonkey 2.53.7.1:
https://crash-stats.mozilla.org/report/ ... 9270210523
... even while using Sidebar History.

Maybe someday it will be fixed but so far I'll stick with no more than 50 entries to delete at once.

Frank Lion

User avatar
 
Posts: 21097
Joined: April 23rd, 2004, 6:59 pm
Location: ... The Exorcist....United Kingdom

Post Posted May 23rd, 2021, 1:48 pm

TPR75 wrote:Maybe someday it will be fixed but so far I'll stick with no more than 50 entries to delete at once.

You could try putting a copy of your usual places.sqlite into a new profile and try mass history deleting in that. That would tell you if it's your usual profile at fault or not.

Btw my places.sqlite is just over 37MB
Metal Lion SeaMonkey Themes - Sea Monkey and Silver Sea Monkey
"The only thing necessary for the triumph of evil, is for good men to do nothing." - Edmund Burke (attrib.)

TPR75
 
Posts: 1111
Joined: July 25th, 2011, 8:11 am
Location: Poland

Post Posted May 28th, 2021, 2:47 pm

Frank Lion wrote:You could try putting a copy of your usual places.sqlite into a new profile and try mass history deleting in that. That would tell you if it's your usual profile at fault or not.


Well... I think I've find reason of crashes.

I tested "places.sqlite" in new profile. SeaMonkey 2.53.9 didn't crashed. I selected c.a. 18000 entries and hit Del. It freezes (CPU 25% which is 100% per one core) but after short time there was warning for unresponsive script. Clicking "Continue" was pointless so I hit "Debug". SeaMonkey freezes for c.a. 15 minutes but RAM was not swallowed like mad (kipped between 780-840 MB) but eventually deleted all entries (but no debug output).

Damn! What is wrong with my (very) old profile? I was suspecting sqlite files but verification was OK (SQLite Manager extension). Maybe there are files which remembers Netscape 4.5 and they are messing here? I didn't know and I decided to not mess with it anymore because I don't have time right now.

Today I had enough with "bad browser's cache behavior". What was that? Oh, it simple. Images opened with browser were not saved to cache and saving them caused to download again. APOD has big pictures:
https://apod.nasa.gov/apod/ap210514.html
(click on image, c.a. 10 MB).

I'm using RAM DISK for SeaMonkey cache. But my old profile didn't save there anything. After some research I find this two preferences:
Code: Select all
browser.cache.disk.enable
browser.cache.disk_cache_ssl

They were set do "false" (bold, non-default). They're responsible for writing cache directly to RAM to save/preserve SSD. But I have RAM DISK already! I've set them both to default "true". I was able to save pictures without downloading them again. Hurray, success!

Cache was redirected to RAM. To RAM, memory... OH-MY-GOD!!! Deleting entries in history was causing SeaMonkey to consume RAM like mad up to limit and crash. Because cache was in RAM.

Final test using copy of my old and default profile. It behave like new profile (see: above) - freezes suite for a while but finished the job. This is it! SeaMonkey can't manage with history cleaning when cache is in memory. This is bugged.

OK! Now I can wait for patched version of SeaMonkey (in some future) without big worries. 8-)

frg
 
Posts: 1153
Joined: December 15th, 2015, 1:20 pm

Post Posted May 28th, 2021, 3:28 pm

> They were set do "false" (bold, non-default). They're responsible for writing cache directly to RAM to save/preserve SSD.

All these SSD optimizing tricks are good on paper only. That modern SSDs are degrading too fast is a myth. I am building in vms only and my system boot drive is also not even at 1% life time after two years. When I still built Nightly, beta and release a few years ago daily I was able to degrade an older 1TB SSD after 2 years to 10% (90% lifetime left). You will not manage this with normal use so just enjoy the show and don't worry about wear.

FRG

Frank Lion

User avatar
 
Posts: 21097
Joined: April 23rd, 2004, 6:59 pm
Location: ... The Exorcist....United Kingdom

Post Posted May 29th, 2021, 12:26 am

frg wrote:All these SSD optimizing tricks are good on paper only.

Ideally should be fixed, but meantime might be worth mentioning in the Release Notes under Known Issues that browser.cache.disk.enable and browser.cache.disk_cache_ssl set to false will cause History deletion crashes/problems.

No one is going to just guess or stumble upon that connection, it's pretty obscure.

***

Good troubleshooting work, TPR75
Metal Lion SeaMonkey Themes - Sea Monkey and Silver Sea Monkey
"The only thing necessary for the triumph of evil, is for good men to do nothing." - Edmund Burke (attrib.)

Return to SeaMonkey Builds


Who is online

Users browsing this forum: No registered users and 2 guests