Re: Awful memory leaks
Mason83 wrote on 29/03/18 01:21: On 28/03/2018 14:31, Daniel wrote: Mason, your User Agent line indicates Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0 In fact, this is *not* the UA string for SM 2.49 It is the UA string for FF 52 ESR, which I hardcoded via general.useragent.override to work around a bug in the dailymotion website. Thanks for reminding me! :-) Regards. No worries, Mason. -- Daniel User agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 SeaMonkey/2.49.1 Build identifier: 20171016030418 User agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 SeaMonkey/2.49.1 Build identifier: 20171015235623 ___ support-seamonkey mailing list support-seamonkey@lists.mozilla.org https://lists.mozilla.org/listinfo/support-seamonkey
Re: Awful memory leaks
On 28/03/2018 14:31, Daniel wrote: > Mason, your User Agent line indicates > Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0 In fact, this is *not* the UA string for SM 2.49 It is the UA string for FF 52 ESR, which I hardcoded via general.useragent.override to work around a bug in the dailymotion website. Thanks for reminding me! :-) Regards. ___ support-seamonkey mailing list support-seamonkey@lists.mozilla.org https://lists.mozilla.org/listinfo/support-seamonkey
Re: Awful memory leaks
Mason83 wrote on 28/03/18 19:22: On 27/03/2018 19:57, IRRITATING SPAMMER wrote: Both of us are using Linux. How did you figure out this was a Linux box? Mason, your User Agent line indicates Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0 So you "told" Ray you were using a Linux build. If you want to display the User Agent line in the Header section, you need to set a line in your Prefs to True. Enter "about:config" (without the inverted commas) in your SeaMonkey Browser's address bar, accept the Warning, then enter "useragent" (without the inverted commas) in the Search: line, and one of the remaining prefs should be "mailnews.headers.showUserAgent" (without the inverted commas). Click on it and you should be able to change it to true. If it doesn't exist, make it. Then when you re-boot your SeaMonkey, the header section of the Mail/Newsgroup display should include a new line, showing what the User Agent of received e-mails and news posts are. -- Daniel User agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 SeaMonkey/2.49.1 Build identifier: 20171016030418 User agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 SeaMonkey/2.49.1 Build identifier: 20171015235623 ___ support-seamonkey mailing list support-seamonkey@lists.mozilla.org https://lists.mozilla.org/listinfo/support-seamonkey
Re: Awful memory leaks
Must have been IRRITATING SPAMMED :-) Mason83 wrote on 28-03-18 10:22: On 27/03/2018 19:57, IRRITATING SPAMMER wrote: You have chosen an odd nickname. Mason83 wrote: There is, as far as I can see, a large memory leak somewhere in the TB code: 2,790,110,536 B (100.0%) -- explicit +--2,359,661,280 B (84.57%) -- maildb ¦ +737,522,464 B (26.43%) -- database(news://SNIP ¦ +692,232,288 B (24.81%) -- database(imap://SNIP ¦ +222,021,472 B (07.96%) -- database(news://SNIP ¦ +180,562,496 B (06.47%) -- database(imap://SNIP ¦ +138,690,496 B (04.97%) -- database(imap://SNIP ¦ +121,302,864 B (04.35%) -- database(snews://SNIP ¦ +-96,929,744 B (03.47%) -- database(snews://SNIP ¦ +-48,629,440 B (01.74%) -- database(imap://SNIP ¦ +-42,458,432 B (01.52%) -- database(snews://SNIP ¦ +-24,473,008 B (00.88%) -- database(imap://SNIP ¦ +-21,606,800 B (00.77%) -- database(news://SNIP ¦ +-10,834,000 B (00.39%) -- database(imap://SNIP ¦ +--5,589,824 B (00.20%) -- database(imap://SNIP ¦ +--4,862,032 B (00.17%) -- database(imap://SNIP ¦ +--3,337,296 B (00.12%) -- database(imap://SNIP ¦ +--2,627,888 B (00.09%) -- database(imap://SNIP ¦ +--1,382,832 B (00.05%) -- database(imap://SNIP ¦ +786,896 B (00.03%) -- database(imap://SNIP ¦ +786,128 B (00.03%) -- database(imap://SNIP ¦ +674,128 B (00.02%) -- database(imap://SNIP ¦ +503,184 B (00.02%) -- database(imap://SNIP ¦ +481,776 B (00.02%) -- database(imap://SNIP ¦ +341,904 B (00.01%) -- database(imap://SNIP ¦ +240,256 B (00.01%) -- database(imap://SNIP ¦ +166,416 B (00.01%) -- database(imap://SNIP ¦ +164,352 B (00.01%) -- database(imap://SNIP ¦ +143,680 B (00.01%) -- database(imap://SNIP ¦ +103,104 B (00.00%) -- database(imap://SNIP ¦ +103,104 B (00.00%) -- database(mailbox://SNIP ¦ +102,976 B (00.00%) -- database(imap://SNIP 737 MB of RAM to store the index of a single newsgroup? And 692 MB for my main inbox? Something looks fishy there. 76 B ── gfx-surface-image 768 B ── gfx-surface-xlib 0 B ── gfx-textures 0 B ── gfx-textures-peak 0 B ── gfx-tiles-waste 0 ── ghost-windows 2,112,485,288 B ── heap-allocated 1,048,576 B ── heap-chunksize 2,320,498,688 B ── heap-mapped 0 ── host-object-urls 24,929,212 B ── imagelib-surface-cache-estimated-locked 24,930,812 B ── imagelib-surface-cache-estimated-total 0 ── imagelib-surface-cache-overflow-count 5,087,232 B ── js-main-runtime-temporary-peak 25,966 ── page-faults-hard 386,639,447 ── page-faults-soft 2,847,887,360 B ── resident 3,155,869,696 B ── resident-peak 2,574,921,728 B ── resident-unique 0 B ── system-heap-allocated 5,839,982,592 B ── vsize 5.8 GB of VM for a few tabs open sounds completely unreasonable. Is there any work around other than quitting/restarting SM? My "explicit" is 522.23 MB maildb is121.81 MB window-objects97.85 MB heap-unclassified 95.55 MB js-non-window 65.23 MB Both of us are using Linux. How did you figure out this was a Linux box? Does it help a bit if you close and reopen the News/Mail part of Seamonkey? I will try. (AFAIR, it doesn't have any impact.) I also don't understand why your figures are in Bytes and mine in MB. I was using 2.49.2 while you seem to be using 2.46 Maybe they changed the reporting format between these versions? Wait... I get "MB" in the Windows version, which is 32-bit while the Linux version is 64-bit. Maybe it takes different code paths... Also note that the "explicit" figure seems to be using a 32-bit variable, and wraps around at 4 GiB. Regards. ___ support-seamonkey mailing list support-seamonkey@lists.mozilla.org https://lists.mozilla.org/listinfo/support-seamonkey
Re: Awful memory leaks
On 27/03/2018 19:57, IRRITATING SPAMMER wrote: You have chosen an odd nickname. > Mason83 wrote: > >> There is, as far as I can see, a large memory leak somewhere >> in the TB code: >> >> 2,790,110,536 B (100.0%) -- explicit >> +--2,359,661,280 B (84.57%) -- maildb >> ¦ +737,522,464 B (26.43%) -- database(news://SNIP >> ¦ +692,232,288 B (24.81%) -- database(imap://SNIP >> ¦ +222,021,472 B (07.96%) -- database(news://SNIP >> ¦ +180,562,496 B (06.47%) -- database(imap://SNIP >> ¦ +138,690,496 B (04.97%) -- database(imap://SNIP >> ¦ +121,302,864 B (04.35%) -- database(snews://SNIP >> ¦ +-96,929,744 B (03.47%) -- database(snews://SNIP >> ¦ +-48,629,440 B (01.74%) -- database(imap://SNIP >> ¦ +-42,458,432 B (01.52%) -- database(snews://SNIP >> ¦ +-24,473,008 B (00.88%) -- database(imap://SNIP >> ¦ +-21,606,800 B (00.77%) -- database(news://SNIP >> ¦ +-10,834,000 B (00.39%) -- database(imap://SNIP >> ¦ +--5,589,824 B (00.20%) -- database(imap://SNIP >> ¦ +--4,862,032 B (00.17%) -- database(imap://SNIP >> ¦ +--3,337,296 B (00.12%) -- database(imap://SNIP >> ¦ +--2,627,888 B (00.09%) -- database(imap://SNIP >> ¦ +--1,382,832 B (00.05%) -- database(imap://SNIP >> ¦ +786,896 B (00.03%) -- database(imap://SNIP >> ¦ +786,128 B (00.03%) -- database(imap://SNIP >> ¦ +674,128 B (00.02%) -- database(imap://SNIP >> ¦ +503,184 B (00.02%) -- database(imap://SNIP >> ¦ +481,776 B (00.02%) -- database(imap://SNIP >> ¦ +341,904 B (00.01%) -- database(imap://SNIP >> ¦ +240,256 B (00.01%) -- database(imap://SNIP >> ¦ +166,416 B (00.01%) -- database(imap://SNIP >> ¦ +164,352 B (00.01%) -- database(imap://SNIP >> ¦ +143,680 B (00.01%) -- database(imap://SNIP >> ¦ +103,104 B (00.00%) -- database(imap://SNIP >> ¦ +103,104 B (00.00%) -- database(mailbox://SNIP >> ¦ +102,976 B (00.00%) -- database(imap://SNIP >> >> >> 737 MB of RAM to store the index of a single newsgroup? >> And 692 MB for my main inbox? Something looks fishy there. >> >> >>76 B ── gfx-surface-image >> 768 B ── gfx-surface-xlib >> 0 B ── gfx-textures >> 0 B ── gfx-textures-peak >> 0 B ── gfx-tiles-waste >> 0 ── ghost-windows >> 2,112,485,288 B ── heap-allocated >> 1,048,576 B ── heap-chunksize >> 2,320,498,688 B ── heap-mapped >> 0 ── host-object-urls >>24,929,212 B ── imagelib-surface-cache-estimated-locked >>24,930,812 B ── imagelib-surface-cache-estimated-total >> 0 ── imagelib-surface-cache-overflow-count >> 5,087,232 B ── js-main-runtime-temporary-peak >> 25,966 ── page-faults-hard >> 386,639,447 ── page-faults-soft >> 2,847,887,360 B ── resident >> 3,155,869,696 B ── resident-peak >> 2,574,921,728 B ── resident-unique >> 0 B ── system-heap-allocated >> 5,839,982,592 B ── vsize >> >> >> 5.8 GB of VM for a few tabs open sounds completely unreasonable. >> >> Is there any work around other than quitting/restarting SM? > > My "explicit" is 522.23 MB > maildb is121.81 MB > window-objects97.85 MB > heap-unclassified 95.55 MB > js-non-window 65.23 MB > > Both of us are using Linux. How did you figure out this was a Linux box? > Does it help a bit if you close and reopen the News/Mail part of Seamonkey? I will try. (AFAIR, it doesn't have any impact.) > I also don't understand why your figures are in Bytes and mine in MB. I was using 2.49.2 while you seem to be using 2.46 Maybe they changed the reporting format between these versions? Wait... I get "MB" in the Windows version, which is 32-bit while the Linux version is 64-bit. Maybe it takes different code paths... Also note that the "explicit" figure seems to be using a 32-bit variable, and wraps around at 4 GiB. Regards. ___ support-seamonkey mailing list support-seamonkey@lists.mozilla.org https://lists.mozilla.org/listinfo/support-seamonkey
Re: Awful memory leaks
Mason83 wrote: Hello, There is, as far as I can see, a large memory leak somewhere in the TB code: 2,790,110,536 B (100.0%) -- explicit +--2,359,661,280 B (84.57%) -- maildb ¦ +737,522,464 B (26.43%) -- database(news://SNIP ¦ +692,232,288 B (24.81%) -- database(imap://SNIP ¦ +222,021,472 B (07.96%) -- database(news://SNIP ¦ +180,562,496 B (06.47%) -- database(imap://SNIP ¦ +138,690,496 B (04.97%) -- database(imap://SNIP ¦ +121,302,864 B (04.35%) -- database(snews://SNIP ¦ +-96,929,744 B (03.47%) -- database(snews://SNIP ¦ +-48,629,440 B (01.74%) -- database(imap://SNIP ¦ +-42,458,432 B (01.52%) -- database(snews://SNIP ¦ +-24,473,008 B (00.88%) -- database(imap://SNIP ¦ +-21,606,800 B (00.77%) -- database(news://SNIP ¦ +-10,834,000 B (00.39%) -- database(imap://SNIP ¦ +--5,589,824 B (00.20%) -- database(imap://SNIP ¦ +--4,862,032 B (00.17%) -- database(imap://SNIP ¦ +--3,337,296 B (00.12%) -- database(imap://SNIP ¦ +--2,627,888 B (00.09%) -- database(imap://SNIP ¦ +--1,382,832 B (00.05%) -- database(imap://SNIP ¦ +786,896 B (00.03%) -- database(imap://SNIP ¦ +786,128 B (00.03%) -- database(imap://SNIP ¦ +674,128 B (00.02%) -- database(imap://SNIP ¦ +503,184 B (00.02%) -- database(imap://SNIP ¦ +481,776 B (00.02%) -- database(imap://SNIP ¦ +341,904 B (00.01%) -- database(imap://SNIP ¦ +240,256 B (00.01%) -- database(imap://SNIP ¦ +166,416 B (00.01%) -- database(imap://SNIP ¦ +164,352 B (00.01%) -- database(imap://SNIP ¦ +143,680 B (00.01%) -- database(imap://SNIP ¦ +103,104 B (00.00%) -- database(imap://SNIP ¦ +103,104 B (00.00%) -- database(mailbox://SNIP ¦ +102,976 B (00.00%) -- database(imap://SNIP 737 MB of RAM to store the index of a single newsgroup? And 692 MB for my main inbox? Something looks fishy there. 76 B ── gfx-surface-image 768 B ── gfx-surface-xlib 0 B ── gfx-textures 0 B ── gfx-textures-peak 0 B ── gfx-tiles-waste 0 ── ghost-windows 2,112,485,288 B ── heap-allocated 1,048,576 B ── heap-chunksize 2,320,498,688 B ── heap-mapped 0 ── host-object-urls 24,929,212 B ── imagelib-surface-cache-estimated-locked 24,930,812 B ── imagelib-surface-cache-estimated-total 0 ── imagelib-surface-cache-overflow-count 5,087,232 B ── js-main-runtime-temporary-peak 25,966 ── page-faults-hard 386,639,447 ── page-faults-soft 2,847,887,360 B ── resident 3,155,869,696 B ── resident-peak 2,574,921,728 B ── resident-unique 0 B ── system-heap-allocated 5,839,982,592 B ── vsize 5.8 GB of VM for a few tabs open sounds completely unreasonable. Is there any work around other than quitting/restarting SM? Regards. My "explicit" is 522.23 MB maildb is121.81 MB window-objects97.85 MB heap-unclassified 95.55 MB js-non-window 65.23 MB Both of us are using Linux. Does it help a bit if you close and reopen the News/Mail part of Seamonkey? I also don't understand why your figures are in Bytes and mine in MB. -- cogito ergo spam ___ support-seamonkey mailing list support-seamonkey@lists.mozilla.org https://lists.mozilla.org/listinfo/support-seamonkey
Awful memory leaks
Hello, There is, as far as I can see, a large memory leak somewhere in the TB code: 2,790,110,536 B (100.0%) -- explicit +--2,359,661,280 B (84.57%) -- maildb ¦ +737,522,464 B (26.43%) -- database(news://SNIP ¦ +692,232,288 B (24.81%) -- database(imap://SNIP ¦ +222,021,472 B (07.96%) -- database(news://SNIP ¦ +180,562,496 B (06.47%) -- database(imap://SNIP ¦ +138,690,496 B (04.97%) -- database(imap://SNIP ¦ +121,302,864 B (04.35%) -- database(snews://SNIP ¦ +-96,929,744 B (03.47%) -- database(snews://SNIP ¦ +-48,629,440 B (01.74%) -- database(imap://SNIP ¦ +-42,458,432 B (01.52%) -- database(snews://SNIP ¦ +-24,473,008 B (00.88%) -- database(imap://SNIP ¦ +-21,606,800 B (00.77%) -- database(news://SNIP ¦ +-10,834,000 B (00.39%) -- database(imap://SNIP ¦ +--5,589,824 B (00.20%) -- database(imap://SNIP ¦ +--4,862,032 B (00.17%) -- database(imap://SNIP ¦ +--3,337,296 B (00.12%) -- database(imap://SNIP ¦ +--2,627,888 B (00.09%) -- database(imap://SNIP ¦ +--1,382,832 B (00.05%) -- database(imap://SNIP ¦ +786,896 B (00.03%) -- database(imap://SNIP ¦ +786,128 B (00.03%) -- database(imap://SNIP ¦ +674,128 B (00.02%) -- database(imap://SNIP ¦ +503,184 B (00.02%) -- database(imap://SNIP ¦ +481,776 B (00.02%) -- database(imap://SNIP ¦ +341,904 B (00.01%) -- database(imap://SNIP ¦ +240,256 B (00.01%) -- database(imap://SNIP ¦ +166,416 B (00.01%) -- database(imap://SNIP ¦ +164,352 B (00.01%) -- database(imap://SNIP ¦ +143,680 B (00.01%) -- database(imap://SNIP ¦ +103,104 B (00.00%) -- database(imap://SNIP ¦ +103,104 B (00.00%) -- database(mailbox://SNIP ¦ +102,976 B (00.00%) -- database(imap://SNIP 737 MB of RAM to store the index of a single newsgroup? And 692 MB for my main inbox? Something looks fishy there. 76 B ── gfx-surface-image 768 B ── gfx-surface-xlib 0 B ── gfx-textures 0 B ── gfx-textures-peak 0 B ── gfx-tiles-waste 0 ── ghost-windows 2,112,485,288 B ── heap-allocated 1,048,576 B ── heap-chunksize 2,320,498,688 B ── heap-mapped 0 ── host-object-urls 24,929,212 B ── imagelib-surface-cache-estimated-locked 24,930,812 B ── imagelib-surface-cache-estimated-total 0 ── imagelib-surface-cache-overflow-count 5,087,232 B ── js-main-runtime-temporary-peak 25,966 ── page-faults-hard 386,639,447 ── page-faults-soft 2,847,887,360 B ── resident 3,155,869,696 B ── resident-peak 2,574,921,728 B ── resident-unique 0 B ── system-heap-allocated 5,839,982,592 B ── vsize 5.8 GB of VM for a few tabs open sounds completely unreasonable. Is there any work around other than quitting/restarting SM? Regards. ___ support-seamonkey mailing list support-seamonkey@lists.mozilla.org https://lists.mozilla.org/listinfo/support-seamonkey
Re: memory leaks in SeaMonkey 2.48
On 4/5/17 3:33 PM, Mason83 wrote: On 28/03/2017 20:58, Mason83 wrote: On 28/03/2017 18:09, David H. Durgee wrote: Looking at the memory report in the browser I see the following: └──-2,644.69 MB (-158.38%) ── heap-unclassified [?!] The memory figure is highlighted in red, so I assume this is a problem. I have the memory report saved and can make it available to you. This looks like some kind of wrap-around of a signed 32-bit variable... Here is a similar report I got (anonymized) Mozilla/5.0 (X11; Linux x86_64; rv:51.0) Gecko/20100101 Firefox/51.0 SeaMonkey/2.48 Build identifier: 20170129231126 PID USER PR NIVIRTRESSHR S %CPU %MEM TIME+ COMMAND 3900 me20 0 3771572 2,184g 118016 S 1,0 56,6 261:21.26 seamonkey Main Process WARNING: the following values are negative or unreasonably large. explicit/(19 tiny) explicit/(19 tiny)/heap-unclassified This indicates a defect in one or more memory reporters. The invalid values are highlighted. Explicit Allocations 2,177.11 MB (100.0%) -- explicit ├──1,717.08 MB (78.87%) -- maildb │ ├482.04 MB (22.14%) ── database(news://XXX) │ ├329.31 MB (15.13%) ── database(imap://XXX) │ ├251.00 MB (11.53%) ── database(news://XXX) │ ├145.23 MB (06.67%) ── database(news://XXX) │ ├─97.12 MB (04.46%) ── database(news://XXX) │ ├─83.93 MB (03.86%) ── database(imap://XXX) │ ├─79.31 MB (03.64%) ── database(imap://XXX) │ ├─75.64 MB (03.47%) ── database(imap://XXX) │ ├─42.90 MB (01.97%) ── database(imap://XXX) │ ├─37.75 MB (01.73%) ++ (16 tiny) │ ├─37.49 MB (01.72%) ── database(imap://XXX) │ ├─28.34 MB (01.30%) ── database(imap://XXX) │ └─27.01 MB (01.24%) ── database(snews://XXX) ├618.48 MB (28.41%) -- window-objects │├──564.71 MB (25.94%) -- top(none) ││ ├──521.49 MB (23.95%) -- detached ││ │ ├──135.31 MB (06.21%) -- window(chrome://messenger/content/messenger.xul) ││ │ │ ├───69.91 MB (03.21%) -- js-compartment([System Principal], about:blank) ││ │ │ │ ├──40.36 MB (01.85%) -- classes ││ │ │ │ │ ├──25.21 MB (01.16%) -- class(Function)/objects ││ │ │ │ │ │ ├──24.79 MB (01.14%) ── gc-heap [46] ││ │ │ │ │ │ └───0.41 MB (00.02%) ── malloc-heap/slots [46] ││ │ │ │ │ └──15.15 MB (00.70%) ++ (6 tiny) ││ │ │ │ └──29.55 MB (01.36%) ++ (6 tiny) ││ │ │ ├───63.92 MB (02.94%) -- dom ││ │ │ │ ├──43.31 MB (01.99%) ── element-nodes [46] ││ │ │ │ └──20.60 MB (00.95%) ++ (4 tiny) ││ │ │ └1.48 MB (00.07%) ++ (2 tiny) ││ │ ├──135.12 MB (06.21%) -- window(chrome://navigator/content/navigator.xul) ││ │ │ ├───85.63 MB (03.93%) -- js-compartment([System Principal], about:blank) ││ │ │ │ ├──46.91 MB (02.15%) -- classes ││ │ │ │ │ ├──35.30 MB (01.62%) -- class(Function)/objects ││ │ │ │ │ │ ├──34.62 MB (01.59%) ── gc-heap [65] ││ │ │ │ │ │ └───0.69 MB (00.03%) ── malloc-heap/slots [65] ││ │ │ │ │ └──11.61 MB (00.53%) ++ (5 tiny) ││ │ │ │ ├──28.09 MB (01.29%) ++ scripts ││ │ │ │ └──10.62 MB (00.49%) ++ (4 tiny) ││ │ │ ├───49.21 MB (02.26%) -- dom ││ │ │ │ ├──35.94 MB (01.65%) ── element-nodes [65] ││ │ │ │ └──13.27 MB (00.61%) ++ (4 tiny) ││ │ │ └0.28 MB (00.01%) ++ (2 tiny) ││ │ ├──112.00 MB (05.14%) -- window(chrome://messenger/content/messageWindow.xul) ││ │ │ ├───66.50 MB (03.05%) -- js-compartment([System Principal], about:blank) ││ │ │ │ ├──38.84 MB (01.78%) -- classes ││ │ │ │ │ ├──28.37 MB (01.30%) -- class(Function)/objects ││ │ │ │ │ │ ├──28.00 MB (01.29%) ── gc-heap [65] ││ │ │ │ │ │ └───0.36 MB (00.02%) ── malloc-heap/slots [65] ││ │ │ │ │ └──10.48 MB (00.48%) ++ (5 tiny) ││ │ │ │ └──27.65 MB (01.27%) ++ (5 tiny) ││ │ │ ├───45.19 MB (02.08%) -- dom ││ │ │ │ ├──31.74 MB (01.46%) ── element-nodes [65] ││ │ │ │ └──13.45 MB (00.62%) ++ (3 tiny) ││ │ │ └0.32 MB (00.01%) ++ (2 tiny) ││ │ ├──101.75 MB (04.67%) -- window(chrome://messenger/content/messengercompose/messengercompose.xul) ││ │ │ ├───63.55 MB (02.92%) -- js-compartment([System Principal], about:blank) ││ │ │ │ ├──34.76 MB (01.60%) -- classes ││ │ │ │ │ ├──26.81 MB (01.23%) -- class(Function)/objects ││ │ │ │ │ │ ├──26.41 MB (01.21%) ── gc-heap [57] ││ │ │ │ │ │ └───0.40 MB (00.02%) ── malloc-heap/slots [57] ││ │ │ │ │ └───7.95 MB (00.37%) ++ (6 tiny) ││ │ │ │ ├──21.81 MB (01.00%) ++ scripts ││ │ │ │ └───6.98 MB (00.32%) ++ (5 tiny) ││ │ │ ├───37.84 MB (01.74%) -- dom ││ │ │ │ ├──27.44 MB (01.26%) ── element-nodes [57] ││ │ │ │ └──10.39 MB (00.48%) ++ (3 tiny) ││ │ │ └0.37 MB (00.02%) ++ (2 tiny) ││ │ └───37.31 MB (01.71%) ++ (9 tiny) ││
Re: memory leaks in SeaMonkey 2.48
On 28/03/2017 20:58, Mason83 wrote: > On 28/03/2017 18:09, David H. Durgee wrote: > >> Looking at the memory report in the browser I see the following: >> >>└──-2,644.69 MB (-158.38%) ── heap-unclassified [?!] >> >> The memory figure is highlighted in red, so I assume this is a problem. >> I have the memory report saved and can make it available to you. > > This looks like some kind of wrap-around of a signed > 32-bit variable... Here is a similar report I got (anonymized) Mozilla/5.0 (X11; Linux x86_64; rv:51.0) Gecko/20100101 Firefox/51.0 SeaMonkey/2.48 Build identifier: 20170129231126 PID USER PR NIVIRTRESSHR S %CPU %MEM TIME+ COMMAND 3900 me20 0 3771572 2,184g 118016 S 1,0 56,6 261:21.26 seamonkey Main Process WARNING: the following values are negative or unreasonably large. explicit/(19 tiny) explicit/(19 tiny)/heap-unclassified This indicates a defect in one or more memory reporters. The invalid values are highlighted. Explicit Allocations 2,177.11 MB (100.0%) -- explicit ├──1,717.08 MB (78.87%) -- maildb │ ├482.04 MB (22.14%) ── database(news://XXX) │ ├329.31 MB (15.13%) ── database(imap://XXX) │ ├251.00 MB (11.53%) ── database(news://XXX) │ ├145.23 MB (06.67%) ── database(news://XXX) │ ├─97.12 MB (04.46%) ── database(news://XXX) │ ├─83.93 MB (03.86%) ── database(imap://XXX) │ ├─79.31 MB (03.64%) ── database(imap://XXX) │ ├─75.64 MB (03.47%) ── database(imap://XXX) │ ├─42.90 MB (01.97%) ── database(imap://XXX) │ ├─37.75 MB (01.73%) ++ (16 tiny) │ ├─37.49 MB (01.72%) ── database(imap://XXX) │ ├─28.34 MB (01.30%) ── database(imap://XXX) │ └─27.01 MB (01.24%) ── database(snews://XXX) ├618.48 MB (28.41%) -- window-objects │├──564.71 MB (25.94%) -- top(none) ││ ├──521.49 MB (23.95%) -- detached ││ │ ├──135.31 MB (06.21%) -- window(chrome://messenger/content/messenger.xul) ││ │ │ ├───69.91 MB (03.21%) -- js-compartment([System Principal], about:blank) ││ │ │ │ ├──40.36 MB (01.85%) -- classes ││ │ │ │ │ ├──25.21 MB (01.16%) -- class(Function)/objects ││ │ │ │ │ │ ├──24.79 MB (01.14%) ── gc-heap [46] ││ │ │ │ │ │ └───0.41 MB (00.02%) ── malloc-heap/slots [46] ││ │ │ │ │ └──15.15 MB (00.70%) ++ (6 tiny) ││ │ │ │ └──29.55 MB (01.36%) ++ (6 tiny) ││ │ │ ├───63.92 MB (02.94%) -- dom ││ │ │ │ ├──43.31 MB (01.99%) ── element-nodes [46] ││ │ │ │ └──20.60 MB (00.95%) ++ (4 tiny) ││ │ │ └1.48 MB (00.07%) ++ (2 tiny) ││ │ ├──135.12 MB (06.21%) -- window(chrome://navigator/content/navigator.xul) ││ │ │ ├───85.63 MB (03.93%) -- js-compartment([System Principal], about:blank) ││ │ │ │ ├──46.91 MB (02.15%) -- classes ││ │ │ │ │ ├──35.30 MB (01.62%) -- class(Function)/objects ││ │ │ │ │ │ ├──34.62 MB (01.59%) ── gc-heap [65] ││ │ │ │ │ │ └───0.69 MB (00.03%) ── malloc-heap/slots [65] ││ │ │ │ │ └──11.61 MB (00.53%) ++ (5 tiny) ││ │ │ │ ├──28.09 MB (01.29%) ++ scripts ││ │ │ │ └──10.62 MB (00.49%) ++ (4 tiny) ││ │ │ ├───49.21 MB (02.26%) -- dom ││ │ │ │ ├──35.94 MB (01.65%) ── element-nodes [65] ││ │ │ │ └──13.27 MB (00.61%) ++ (4 tiny) ││ │ │ └0.28 MB (00.01%) ++ (2 tiny) ││ │ ├──112.00 MB (05.14%) -- window(chrome://messenger/content/messageWindow.xul) ││ │ │ ├───66.50 MB (03.05%) -- js-compartment([System Principal], about:blank) ││ │ │ │ ├──38.84 MB (01.78%) -- classes ││ │ │ │ │ ├──28.37 MB (01.30%) -- class(Function)/objects ││ │ │ │ │ │ ├──28.00 MB (01.29%) ── gc-heap [65] ││ │ │ │ │ │ └───0.36 MB (00.02%) ── malloc-heap/slots [65] ││ │ │ │ │ └──10.48 MB (00.48%) ++ (5 tiny) ││ │ │ │ └──27.65 MB (01.27%) ++ (5 tiny) ││ │ │ ├───45.19 MB (02.08%) -- dom ││ │ │ │ ├──31.74 MB (01.46%) ── element-nodes [65] ││ │ │ │ └──13.45 MB (00.62%) ++ (3 tiny) ││ │ │ └0.32 MB (00.01%) ++ (2 tiny) ││ │ ├──101.75 MB (04.67%) -- window(chrome://messenger/content/messengercompose/messengercompose.xul) ││ │ │ ├───63.55 MB (02.92%) -- js-compartment([System Principal], about:blank) ││ │ │ │ ├──34.76 MB (01.60%) -- classes ││ │ │ │ │ ├──26.81 MB (01.23%) -- class(Function)/objects ││ │ │ │ │ │ ├──26.41 MB (01.21%) ── gc-heap [57] ││ │ │ │ │ │ └───0.40 MB (00.02%) ── malloc-heap/slots [57] ││ │ │ │ │ └───7.95 MB (00.37%) ++ (6 tiny) ││ │ │ │ ├──21.81 MB (01.00%) ++ scripts ││ │ │ │ └───6.98 MB (00.32%) ++ (5 tiny) ││ │ │ ├───37.84 MB (01.74%) -- dom ││ │ │ │ ├──27.44 MB (01.26%) ── element-nodes [57] ││ │ │ │ └
Re: memory leaks in SeaMonkey 2.48
> Does that mean that the site where one downloads SeaMonkey is going to > change? No its an internal thing. The bata builds are done but now comes the fun part of moving them to the right places so might need another build: https://archive.mozilla.org/pub/seamonkey/candidates/2.48b1-candidates/build7/ I hope this works out fine soon so that the regular 2.48 can be done. 2.48/2.49 is already late. FRG EE wrote: Frank-Rainer Grahl wrote: Still probably at least 3-4 weeks away. Ewong is currently on 2.48 beta to iron out switching to new distribution servers and we bad infrastructure issues galore. The beta will be followed by a regular 2.48 and then hopefully a 2.49 from the ESR tree fast. Does that mean that the site where one downloads SeaMonkey is going to change? ___ support-seamonkey mailing list support-seamonkey@lists.mozilla.org https://lists.mozilla.org/listinfo/support-seamonkey
Re: memory leaks in SeaMonkey 2.48
On 31/03/2017 4:47 AM, EE wrote: Frank-Rainer Grahl wrote: Still probably at least 3-4 weeks away. Ewong is currently on 2.48 beta to iron out switching to new distribution servers and we bad infrastructure issues galore. The beta will be followed by a regular 2.48 and then hopefully a 2.49 from the ESR tree fast. Does that mean that the site where one downloads SeaMonkey is going to change? I would guess Physically, YES but address-wise, NO. At least I hope!! -- Daniel User agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:49.0) Gecko/20100101 SeaMonkey/2.46 Build identifier: 20161213183751 ___ support-seamonkey mailing list support-seamonkey@lists.mozilla.org https://lists.mozilla.org/listinfo/support-seamonkey
Re: memory leaks in SeaMonkey 2.48
Frank-Rainer Grahl wrote: Still probably at least 3-4 weeks away. Ewong is currently on 2.48 beta to iron out switching to new distribution servers and we bad infrastructure issues galore. The beta will be followed by a regular 2.48 and then hopefully a 2.49 from the ESR tree fast. Does that mean that the site where one downloads SeaMonkey is going to change? ___ support-seamonkey mailing list support-seamonkey@lists.mozilla.org https://lists.mozilla.org/listinfo/support-seamonkey
Re: memory leaks in SeaMonkey 2.48
On 28/03/2017 18:09, David H. Durgee wrote: > Looking at the memory report in the browser I see the following: > >└──-2,644.69 MB (-158.38%) ── heap-unclassified [?!] > > The memory figure is highlighted in red, so I assume this is a problem. > I have the memory report saved and can make it available to you. This looks like some kind of wrap-around of a signed 32-bit variable... I have, for sure, seen this with 2.47 and 2.48 I haven't yet upgraded, I'll try ASAP. Regards. ___ support-seamonkey mailing list support-seamonkey@lists.mozilla.org https://lists.mozilla.org/listinfo/support-seamonkey
Re: memory leaks in SeaMonkey 2.48
> > I have not as yet tried it. Only a manual install is available at present, so > I was waiting on Ubuntuzilla to get back to a "normal" update method. Still probably at least 3-4 weeks away. Ewong is currently on 2.48 beta to iron out switching to new distribution servers and we bad infrastructure issues galore. The beta will be followed by a regular 2.48 and then hopefully a 2.49 from the ESR tree fast. Really s*cks when the software is ready and the release process isn't. FRG David H. Durgee wrote: Frank-Rainer Grahl wrote: └──-2,644.69 MB (-158.38%) ── heap-unclassified [?!] If you press GC under Free Memory does it get back to normal? No. I also tried the "minimize memory" there. After running these the memory figures were still as bad if not worse. You can send me the report together with the output of about:support (use copy text to clipboard). I am no expert here so don't have high hopes. I will send you a copy. Did you try Adrians 2.49 yet? TB fixed some long standing issues in 2.49. I had trouble with IMAP access prior to 2.49 and even saw a crash now and then. Very stable now. Also 2.48 is the first version using cache2 as the default. There might be some additional fixes in 2.49. I have not as yet tried it. Only a manual install is available at present, so I was waiting on Ubuntuzilla to get back to a "normal" update method. Dave FRG David H. Durgee wrote: Looking at the memory report in the browser I see the following: └──-2,644.69 MB (-158.38%) ── heap-unclassified [?!] The memory figure is highlighted in red, so I assume this is a problem. I have the memory report saved and can make it available to you. Dave Frank-Rainer Grahl wrote: Maybe you can check with about:memory and open a bug if you find something. For me I found that Amazon seems to cause some problems over time. These are likely Gecko problems and will also occur in Firefox but probably some might be SeaMonkey or extension specific. FRG David H. Durgee wrote: I am currently running Adrian's 64 bit build on linux mint 17.2 x64 and am noticing what I can only assume is a memory leak over time. I just had to restart SM when my system usage showed it using 1.7GB of memory! After restarting it now reports 725MB used, so this is quite an improvement. I tend to avoid restarts until necessary as I keep multiple tabs open and some of them require me to login again after a restart. Perhaps it would be possible to do a "softer" restart of some sort at some point and avoid this? I know that security issues are primary, but can memory leaks be looked into at some point? If they can't be addressed easily, as they might be specific to particular builds as opposed to general, then perhaps at least it might be possible to implement some sort of a "restart" option that would avoid the problems associated with a complete shutdown/launch cycle imposes? Dave ___ support-seamonkey mailing list support-seamonkey@lists.mozilla.org https://lists.mozilla.org/listinfo/support-seamonkey
Re: memory leaks in SeaMonkey 2.48
Frank-Rainer Grahl wrote: └──-2,644.69 MB (-158.38%) ── heap-unclassified [?!] If you press GC under Free Memory does it get back to normal? No. I also tried the "minimize memory" there. After running these the memory figures were still as bad if not worse. You can send me the report together with the output of about:support (use copy text to clipboard). I am no expert here so don't have high hopes. I will send you a copy. Did you try Adrians 2.49 yet? TB fixed some long standing issues in 2.49. I had trouble with IMAP access prior to 2.49 and even saw a crash now and then. Very stable now. Also 2.48 is the first version using cache2 as the default. There might be some additional fixes in 2.49. I have not as yet tried it. Only a manual install is available at present, so I was waiting on Ubuntuzilla to get back to a "normal" update method. Dave FRG David H. Durgee wrote: Looking at the memory report in the browser I see the following: └──-2,644.69 MB (-158.38%) ── heap-unclassified [?!] The memory figure is highlighted in red, so I assume this is a problem. I have the memory report saved and can make it available to you. Dave Frank-Rainer Grahl wrote: Maybe you can check with about:memory and open a bug if you find something. For me I found that Amazon seems to cause some problems over time. These are likely Gecko problems and will also occur in Firefox but probably some might be SeaMonkey or extension specific. FRG David H. Durgee wrote: I am currently running Adrian's 64 bit build on linux mint 17.2 x64 and am noticing what I can only assume is a memory leak over time. I just had to restart SM when my system usage showed it using 1.7GB of memory! After restarting it now reports 725MB used, so this is quite an improvement. I tend to avoid restarts until necessary as I keep multiple tabs open and some of them require me to login again after a restart. Perhaps it would be possible to do a "softer" restart of some sort at some point and avoid this? I know that security issues are primary, but can memory leaks be looked into at some point? If they can't be addressed easily, as they might be specific to particular builds as opposed to general, then perhaps at least it might be possible to implement some sort of a "restart" option that would avoid the problems associated with a complete shutdown/launch cycle imposes? Dave ___ support-seamonkey mailing list support-seamonkey@lists.mozilla.org https://lists.mozilla.org/listinfo/support-seamonkey
Re: memory leaks in SeaMonkey 2.48
>└──-2,644.69 MB (-158.38%) ── heap-unclassified [?!] If you press GC under Free Memory does it get back to normal? You can send me the report together with the output of about:support (use copy text to clipboard). I am no expert here so don't have high hopes. Did you try Adrians 2.49 yet? TB fixed some long standing issues in 2.49. I had trouble with IMAP access prior to 2.49 and even saw a crash now and then. Very stable now. Also 2.48 is the first version using cache2 as the default. There might be some additional fixes in 2.49. FRG David H. Durgee wrote: Looking at the memory report in the browser I see the following: └──-2,644.69 MB (-158.38%) ── heap-unclassified [?!] The memory figure is highlighted in red, so I assume this is a problem. I have the memory report saved and can make it available to you. Dave Frank-Rainer Grahl wrote: Maybe you can check with about:memory and open a bug if you find something. For me I found that Amazon seems to cause some problems over time. These are likely Gecko problems and will also occur in Firefox but probably some might be SeaMonkey or extension specific. FRG David H. Durgee wrote: I am currently running Adrian's 64 bit build on linux mint 17.2 x64 and am noticing what I can only assume is a memory leak over time. I just had to restart SM when my system usage showed it using 1.7GB of memory! After restarting it now reports 725MB used, so this is quite an improvement. I tend to avoid restarts until necessary as I keep multiple tabs open and some of them require me to login again after a restart. Perhaps it would be possible to do a "softer" restart of some sort at some point and avoid this? I know that security issues are primary, but can memory leaks be looked into at some point? If they can't be addressed easily, as they might be specific to particular builds as opposed to general, then perhaps at least it might be possible to implement some sort of a "restart" option that would avoid the problems associated with a complete shutdown/launch cycle imposes? Dave ___ support-seamonkey mailing list support-seamonkey@lists.mozilla.org https://lists.mozilla.org/listinfo/support-seamonkey
Re: memory leaks in SeaMonkey 2.48
Looking at the memory report in the browser I see the following: └──-2,644.69 MB (-158.38%) ── heap-unclassified [?!] The memory figure is highlighted in red, so I assume this is a problem. I have the memory report saved and can make it available to you. Dave Frank-Rainer Grahl wrote: Maybe you can check with about:memory and open a bug if you find something. For me I found that Amazon seems to cause some problems over time. These are likely Gecko problems and will also occur in Firefox but probably some might be SeaMonkey or extension specific. FRG David H. Durgee wrote: I am currently running Adrian's 64 bit build on linux mint 17.2 x64 and am noticing what I can only assume is a memory leak over time. I just had to restart SM when my system usage showed it using 1.7GB of memory! After restarting it now reports 725MB used, so this is quite an improvement. I tend to avoid restarts until necessary as I keep multiple tabs open and some of them require me to login again after a restart. Perhaps it would be possible to do a "softer" restart of some sort at some point and avoid this? I know that security issues are primary, but can memory leaks be looked into at some point? If they can't be addressed easily, as they might be specific to particular builds as opposed to general, then perhaps at least it might be possible to implement some sort of a "restart" option that would avoid the problems associated with a complete shutdown/launch cycle imposes? Dave ___ support-seamonkey mailing list support-seamonkey@lists.mozilla.org https://lists.mozilla.org/listinfo/support-seamonkey
Re: memory leaks in SeaMonkey 2.48
I waited a bit after restarting SeaMonkey and now that it appears to be eating a lot of memory ran the about:memory as suggested. The report does appear to show some problems with memory management as there were red highlighted entries. I have never looked at this before, but it appears to be in the mail/news component if I read it correctly. I saved the memory management display. I will open a bug if you like, or I could make it available for someone with more expertise than I have to inspect it first to ensure I am not misunderstanding the report and wasting the developer's time with this. As I understand it is not possible to attach a file to a post here, so I will wait for a response before taking any action. Dave Frank-Rainer Grahl wrote: Maybe you can check with about:memory and open a bug if you find something. For me I found that Amazon seems to cause some problems over time. These are likely Gecko problems and will also occur in Firefox but probably some might be SeaMonkey or extension specific. FRG David H. Durgee wrote: I am currently running Adrian's 64 bit build on linux mint 17.2 x64 and am noticing what I can only assume is a memory leak over time. I just had to restart SM when my system usage showed it using 1.7GB of memory! After restarting it now reports 725MB used, so this is quite an improvement. I tend to avoid restarts until necessary as I keep multiple tabs open and some of them require me to login again after a restart. Perhaps it would be possible to do a "softer" restart of some sort at some point and avoid this? I know that security issues are primary, but can memory leaks be looked into at some point? If they can't be addressed easily, as they might be specific to particular builds as opposed to general, then perhaps at least it might be possible to implement some sort of a "restart" option that would avoid the problems associated with a complete shutdown/launch cycle imposes? Dave ___ support-seamonkey mailing list support-seamonkey@lists.mozilla.org https://lists.mozilla.org/listinfo/support-seamonkey
Re: memory leaks in SeaMonkey 2.48
TCW wrote: On Tue, 21 Mar 2017 16:12:30 -0400, "David H. Durgee" wrote: I am currently running Adrian's 64 bit build on linux mint 17.2 x64 and am noticing what I can only assume is a memory leak over time. I just had to restart SM when my system usage showed it using 1.7GB of memory! After restarting it now reports 725MB used, so this is quite an improvement. I tend to avoid restarts until necessary as I keep multiple tabs open and some of them require me to login again after a restart. Perhaps it would be possible to do a "softer" restart of some sort at some point and avoid this? I know that security issues are primary, but can memory leaks be looked into at some point? If they can't be addressed easily, as they might be specific to particular builds as opposed to general, then perhaps at least it might be possible to implement some sort of a "restart" option that would avoid the problems associated with a complete shutdown/launch cycle imposes? Dave No 2.49 available for Mint? It's in the Linux directory. I did see memory leakage with 2.49 myself so it may not hold much hope for you on Linux. I'm on 2.50 (Winx64) myself but it's crashy as heck but no leakage that I can see like with the older versions. I am only running Adrian's build while waiting for an official release via Ubuntuzilla. I finally installed Adrian's when there was warnings about the out of date 2.26 requiring immediate action. I had to install Adrian's build by hand, so it was only the urgency that lead me to do so. At this point I am unaware of any sufficiently urgent issues for me to do so again. I am receiving notices about 2.49 now, but once again it would be a manual update. Dave ___ support-seamonkey mailing list support-seamonkey@lists.mozilla.org https://lists.mozilla.org/listinfo/support-seamonkey
Re: memory leaks in SeaMonkey 2.48
Hmm two seem to be startup crashes. I think there were some problems recently solved in Gecko / Firefox. Need to check if we picked up all patches there. But running 2.50 for quite some time now in a vm and didn't experience them yet. Third is a problem with some Nvidia dll. If not done yet might be time to update the video driver. FRG TCW wrote: On Wed, 22 Mar 2017 11:24:15 +0100, Frank-Rainer Grahl wrote: 2.50 has a few problems but didn't crash on me yet. Any specifics? FRG TCW wrote: I'm on 2.50 (Winx64) myself but it's crashy as heck but no leakage that I can see like with the older versions. https://crash-stats.mozilla.com/report/index/018b4494-102e-4b9a-8c11-3efa72170317 https://crash-stats.mozilla.com/report/index/39c833b8-b325-4bd2-8a77-6f11d2170317 https://crash-stats.mozilla.com/report/index/9a95957e-a2ee-4277-900f-153dd2170319 ___ support-seamonkey mailing list support-seamonkey@lists.mozilla.org https://lists.mozilla.org/listinfo/support-seamonkey
Re: memory leaks in SeaMonkey 2.48
David H. Durgee wrote: > I am currently running Adrian's 64 bit build on linux mint 17.2 x64 and > am noticing what I can only assume is a memory leak over time. I just > had to restart SM when my system usage showed it using 1.7GB of memory! > After restarting it now reports 725MB used, so this is quite an improvement. > > I tend to avoid restarts until necessary as I keep multiple tabs open > and some of them require me to login again after a restart. Perhaps it > would be possible to do a "softer" restart of some sort at some point > and avoid this? > > I know that security issues are primary, but can memory leaks be looked > into at some point? If they can't be addressed easily, as they might be > specific to particular builds as opposed to general, then perhaps at > least it might be possible to implement some sort of a "restart" option > that would avoid the problems associated with a complete shutdown/launch > cycle imposes? > > Dave > I get some problems when I log into Netflix. I am not sure if it is a memory leak. But my system has only 1G of RAM, and when I log into Netflix, it goes swaptastic. The same problem was occurring with Firefox but then it went away with a newer release, so I was hoping the same thing would happen with SeaMonkey eventually. Opensuse 42.2 Seamonkey 2.49a2 and 2.50a2, compiled by me. (Maybe earlier ones, I can't remember). ___ support-seamonkey mailing list support-seamonkey@lists.mozilla.org https://lists.mozilla.org/listinfo/support-seamonkey
Re: memory leaks in SeaMonkey 2.48
2.50 has a few problems but didn't crash on me yet. Any specifics? FRG TCW wrote: I'm on 2.50 (Winx64) myself but it's crashy as heck but no leakage that I can see like with the older versions. ___ support-seamonkey mailing list support-seamonkey@lists.mozilla.org https://lists.mozilla.org/listinfo/support-seamonkey
Re: memory leaks in SeaMonkey 2.48
Maybe you can check with about:memory and open a bug if you find something. For me I found that Amazon seems to cause some problems over time. These are likely Gecko problems and will also occur in Firefox but probably some might be SeaMonkey or extension specific. FRG David H. Durgee wrote: I am currently running Adrian's 64 bit build on linux mint 17.2 x64 and am noticing what I can only assume is a memory leak over time. I just had to restart SM when my system usage showed it using 1.7GB of memory! After restarting it now reports 725MB used, so this is quite an improvement. I tend to avoid restarts until necessary as I keep multiple tabs open and some of them require me to login again after a restart. Perhaps it would be possible to do a "softer" restart of some sort at some point and avoid this? I know that security issues are primary, but can memory leaks be looked into at some point? If they can't be addressed easily, as they might be specific to particular builds as opposed to general, then perhaps at least it might be possible to implement some sort of a "restart" option that would avoid the problems associated with a complete shutdown/launch cycle imposes? Dave ___ support-seamonkey mailing list support-seamonkey@lists.mozilla.org https://lists.mozilla.org/listinfo/support-seamonkey
memory leaks in SeaMonkey 2.48
I am currently running Adrian's 64 bit build on linux mint 17.2 x64 and am noticing what I can only assume is a memory leak over time. I just had to restart SM when my system usage showed it using 1.7GB of memory! After restarting it now reports 725MB used, so this is quite an improvement. I tend to avoid restarts until necessary as I keep multiple tabs open and some of them require me to login again after a restart. Perhaps it would be possible to do a "softer" restart of some sort at some point and avoid this? I know that security issues are primary, but can memory leaks be looked into at some point? If they can't be addressed easily, as they might be specific to particular builds as opposed to general, then perhaps at least it might be possible to implement some sort of a "restart" option that would avoid the problems associated with a complete shutdown/launch cycle imposes? Dave ___ support-seamonkey mailing list support-seamonkey@lists.mozilla.org https://lists.mozilla.org/listinfo/support-seamonkey
Memory leaks
I use seamonkey 1.1.1 through a gecko's project on ATM. I have memory leaks, but I dont know if the cause is in my code or elsewhere. I built seamonkey with the followings options (On windows XP) mk_add_options MOZ_CO_PROJECT=suite ac_add_options --enable-application=suite mk_add_options moz_objd...@topsrcdir@/suite-opt ac_add_options --disable-optimize ac_add_options --enable-debug ac_add_options --enable-debugger-info-modules=yes ac_add_options --disable-mailnews ac_add_options --disable-ldap ac_add_options --disable-installer ac_add_options --disable-tests ac_add_options --enable-logging ac_add_options --enable-perf-metrics ac_add_options --disable-logrefcnt ac_add_options --enable-shark ac_add_options --enable-dtrace ac_add_options --enable-boehm ac_add_options --disable-trace-malloc ac_add_options --enable-detect-webshell-leaks ac_add_options --disable-strip I set the variables XPCOM_MEM_BLOAT_LOG=c:\membloat.log XPCOM_MEM_LEAK_LOG=c:\memleak.log XPCOM_MEM_LEAKY_LOG=c:\memleaky.log NSPR_LOG_MODULES=DOMLeak:5,DocumentLeak:5,nsDocShellLeak: 5,NodeInfoManagerLeak:5 NSPR_LOG_FILE=c:\nspr.log I got a nspr.log and a membloat.log Into membloat.log I see |<Class--->|<-Bytes-->| <Objects>|<-- References-->| Per-Inst Leaked Total Rem Mean StdDev Total Rem Mean StdDev 0 TOTAL46604 226079959 18 ( 143,84 +/- 155,01) 530852048 32 ( 72,74 +/- 120,68) 1 AtomImpl12 36 229957 3 ( 93,44 +/- 1,96) 48592083 ( 286,67 +/-25,19) 56 XPCNativeScriptableShared 108 108 828812 1 (8,50 +/- 0,50) 00 (0,00 +/- 0,00) 58 XPCWrappedNative 4848 11866431 ( 54,15 +/-14,52) 291953051 ( 59,97 +/-16,00) 85 nsBaseDragService 44 44 11 (1,00 +/- 0,00) 4294168 (9,00 +/- 1,08) 290 nsNativeDragTarget 24 192 1431378 (5,00 +/- 0,71) 715677 16 ( 15,40 +/- 1,78) 368 nsSupportsArray 52 52 9483371 ( 51,34 +/- 1,03) 23007021 ( 52,88 +/- 1,18) 379 nsThread24 24 6 1 (3,27 +/- 1,68) 26491401 ( 19,26 +/- 0,73) 380 nsTimerImpl48 48 157318 1 (5,03 +/- 0,96)6559111 ( 10,29 +/- 1,78) 417 nsXPCComponents 52 52 214711 1 ( 10,10 +/- 2,56) 17176881 ( 27,17 +/- 8,23) I didn't show the lines with leaked=0 Are these logs normal ? Is there a memory leak ? What can I do else, more logs .. thank's for your responses philippe ___ support-seamonkey mailing list support-seamonkey@lists.mozilla.org https://lists.mozilla.org/listinfo/support-seamonkey
