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:
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.
SeaMonkey 2.53.9b1pre Library crash
-
- Posts: 1353
- Joined: July 25th, 2011, 8:11 am
- Location: Poland
-
- Posts: 1361
- Joined: December 15th, 2015, 1:20 pm
Re: SeaMonkey 2.53.9b1pre Library crash
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.
-
- Posts: 1353
- Joined: July 25th, 2011, 8:11 am
- Location: Poland
Re: SeaMonkey 2.53.9b1pre Library crash
It could be this bug:frg wrote:Need to look up the ones from the builder to see where it did go south.
https://bugzilla.mozilla.org/show_bug.cgi?id=1562490
--
-
- Posts: 1361
- Joined: December 15th, 2015, 1:20 pm
Re: SeaMonkey 2.53.9b1pre Library crash
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
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
- Posts: 21177
- Joined: April 23rd, 2004, 6:59 pm
- Location: ... The Exorcist....United Kingdom
- Contact:
Re: SeaMonkey 2.53.9b1pre Library crash
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)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.
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.
"The only thing necessary for the triumph of evil, is for good men to do nothing." - Edmund Burke (attrib.)
.
.
-
- Posts: 1353
- Joined: July 25th, 2011, 8:11 am
- Location: Poland
Re: SeaMonkey 2.53.9b1pre Library crash
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...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.
I've checked places.sqlite integrity and done compacting. This file isn't small (55 MB). Sorting is from latest (top view).
--
-
- Posts: 1353
- Joined: July 25th, 2011, 8:11 am
- Location: Poland
Re: SeaMonkey 2.53.9b1pre Library crash
Unfortunately, more than 1000-1500 entries crashed SeaMonkey 2.53.7.1: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.
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
- Posts: 21177
- Joined: April 23rd, 2004, 6:59 pm
- Location: ... The Exorcist....United Kingdom
- Contact:
Re: SeaMonkey 2.53.9b1pre Library crash
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.TPR75 wrote:Maybe someday it will be fixed but so far I'll stick with no more than 50 entries to delete at once.
Btw my places.sqlite is just over 37MB
"The only thing necessary for the triumph of evil, is for good men to do nothing." - Edmund Burke (attrib.)
.
.
-
- Posts: 1353
- Joined: July 25th, 2011, 8:11 am
- Location: Poland
Re: SeaMonkey 2.53.9b1pre Library crash
Well... I think I've find reason of crashes.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.
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
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.
--
-
- Posts: 1361
- Joined: December 15th, 2015, 1:20 pm
Re: SeaMonkey 2.53.9b1pre Library crash
> 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
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
- Posts: 21177
- Joined: April 23rd, 2004, 6:59 pm
- Location: ... The Exorcist....United Kingdom
- Contact:
Re: SeaMonkey 2.53.9b1pre Library crash
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.frg wrote:All these SSD optimizing tricks are good on paper only.
No one is going to just guess or stumble upon that connection, it's pretty obscure.
***
Good troubleshooting work, TPR75
"The only thing necessary for the triumph of evil, is for good men to do nothing." - Edmund Burke (attrib.)
.
.