Closed
Bug 901370
Opened 11 years ago
Closed 9 years ago
Cannot open 5000 iframes from local file (approximately from 20. Jul)
Categories
(SeaMonkey :: General, defect)
Tracking
(Not tracked)
RESOLVED
WORKSFORME
People
(Reporter: vlposta, Unassigned)
Details
Attachments
(11 files, 8 obsolete files)
144.28 KB,
image/gif
|
Details | |
146.94 KB,
image/gif
|
Details | |
411.22 KB,
application/octet-stream
|
Details | |
421.98 KB,
application/octet-stream
|
Details | |
163.85 KB,
image/gif
|
Details | |
1.36 MB,
application/octet-stream
|
Details | |
173.46 KB,
image/gif
|
Details | |
173.75 KB,
image/gif
|
Details | |
10.77 KB,
text/plain
|
Details | |
9.33 KB,
text/plain
|
Details | |
3.58 KB,
text/plain
|
Details |
User Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Firefox/24.0 SeaMonkey/2.21a1 (Beta/Release) Build ID: 20130621003008 Steps to reproduce: I require open local *.html file contain 5000 iframes with (approximately) these structure: <iframe width="95%" height="20px" src="http://xxx.xxx.xx/call.fcgi?akce=js&hashId=1993330914" scrolling="none"></iframe> SeaMonkey 2.21 (in Safe Mode) open these iframes in short order "one by one" and display imediately result from iframes too "one by one " (on slower computer with Windows Vista 4GB RAM once in a while crashes, but on fast computer with Windows 8 64bit and 8GB RAM work properly always) Actual results: But SeaMonkey 2.22 aproximately from 20. th July before (long time) "alocate memory", after memory ist alocated (to long time...) "send iframes to server" (result not dislpayed) and after all iframes sended, at the moment display result, but often crasch before display result. Expected results: SeaMonkey 2.22 aproximately from 20. th July is much slower and crasch (if open 5000 iframes from file) much more often than SeaMonkey 2.21 and i mus use (oldest) Seamonkey 2.21 :-(
Can you share that file for testing? Also, is Firefox Nightly behaves same?
Reporter | ||
Comment 2•11 years ago
|
||
For testing this file unfortunately needed my username and password - i mus testing it himself ... :-( In FireFox 25.0a1 (2013-08-04) i open this files properly (iframes open and display immediately "one by one" like in SeaMonkey 2.21), but FireFox only wait more time after open all iframes and before responding and write "Done" to status line. Have You please any builds 2.22 near 20 th July to i identify which build 2.22 work properly ???
You can try to use mozregression - https://wiki.mozilla.org/Auto-tools/Projects/RegressionHunter#mozregression
Reporter | ||
Comment 4•11 years ago
|
||
How to please use mozregression for SeaMonkey ??? With "mozregression --good=2010-03-16" downloaded only builds of FireFox, but "mozregression --app=seamonkey" is not funcional... :-(
Reporter | ||
Comment 5•11 years ago
|
||
After i mozregression not needed, how to uinstal it COMPLETELY please ??? Only (manualy) delete: C:\Users\Vlada\firefox-25.0a1.en-US.win32.zip C:\Users\Vlada\moznightlyapp\firefox C:\mozilla-build\*.* or exist uinstaller for mozregression too please ???
1) Try --repo=comm-central 2) Yeah, just deleting it's folders is enough
Reporter | ||
Comment 7•11 years ago
|
||
With --repo=comm-central i download (huge) directory ".moz-commitbuilder-cache" but no binaries from SeaMonkey. I now find better place with of oldesf build SeaMonkey: http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/?C=M;O=D I now can DELETE (unnecessary) directories from mozregression ??? This is all, or ANOTHER files and directories from mozregression exist please ??? C:\Users\Vlada\firefox-25.0a1.en-US.win32.zip C:\Users\Vlada\moznightlyapp\firefox C:\mozilla-build\*.*
Reporter | ||
Comment 8•11 years ago
|
||
Now i identify that in build 20130718003001 open 5000 iframes PROPERLY, but in build from 20 th Jul really mentioned problem (alocate memory before open and display content of iframes, longest time and often crasch before display all iframes). In build 20130718003001 i open approximately 7000-8000 iframes - is please possible modify SeaMonkey that open much more iframes without crash ??? (with 5000 iframes alocated 8GB memory only to 30%)
Reporter | ||
Comment 10•11 years ago
|
||
At the moment i have unfortunately all previous (to many) crash ids deleted :-( Now i have better computer, where 5000 iframes crashed not often, but problem with much slower reading in latest builds of SeaMonkey persist - i merge all html files with 5000 iframes - come to being file with approximately 80000 iframes and testing with these file: https://crash-stats.mozilla.com/report/index/b675f25b-8a8c-4a8a-abbe-684322130809
Reporter | ||
Comment 11•11 years ago
|
||
Open 80000 iframes from local file in Normal Mode, but no Addons instaled: https://crash-stats.mozilla.com/report/index/ffb46d43-a94f-438a-902c-e12fb2130809
Comment 12•11 years ago
|
||
Both reports contain garbage data as if they are out of memory crashes, can you try to capture memory usage of SeaMonkey near to crash with Rammap tool?
Reporter | ||
Comment 13•11 years ago
|
||
I now download Rammap tool - what interesting you concretely and how to use it for SeaMonkey only please ?
Comment 14•11 years ago
|
||
Ah, my bad, though about VMMap, but writed Rammap, you need first one, run it, select SeaMonkey, start your test with iframes, refresh data in VMMap by pressing F5 every second or two, when SeaMonkey crashes make screenshot of VMMap window and attach it here
Reporter | ||
Comment 15•11 years ago
|
||
Open file with 80000 iframes (i have 8GB RAM), and make scereenschot near before SeaMonkey crashes - after crashes, process SeaMonkey in VMMap not awailable...
Reporter | ||
Comment 16•11 years ago
|
||
This is result near crash from (FASTEST and BETTER) old build 20130718003001 which not alocate RAM before open iframes and display it directly. With 80000 iframes crashes too (80000 maybe is many, but need for me 80000 and more ideal) - this screenschot is for compare (different) RAM alocation from old (better) and new (bad) build only ...
Reporter | ||
Comment 17•11 years ago
|
||
Open file with 80000 iframes (i have 8GB RAM), and make scereenschot near before SeaMonkey crashes - after crashes, process SeaMonkey in VMMap not awailable...
Attachment #788573 -
Attachment is obsolete: true
Reporter | ||
Comment 18•11 years ago
|
||
Comment on attachment 788639 [details]
SeaMonkey_!New_80000_before_Crash.gif
Open file with 80000 iframes in new build 20130810003001 (i have 8GB RAM), and make scereenschot near before SeaMonkey crashes - after crashes, process SeaMonkey in VMMap not awailable...
(previous result maybe too late after crash...)
Reporter | ||
Comment 19•11 years ago
|
||
If open 5300 iframes in LATEST build (on new computer with 8GB RAM) SeaMonkey no crashes (but open it much slower) - this result is only for compare RAM alocation after all 5300 iframes (suscefully) opened in (better) old and latest build of SeaMonkey ...
Reporter | ||
Comment 20•11 years ago
|
||
If open 5300 iframes in OLD build 20130718003001 (on new computer with 8GB RAM) SeaMonkey no crashes (and open it much FASTEST - no alocate RAM before open iframes) - this result is only for compare RAM alocation after all 5300 iframes (suscefully) opened in (better) old and latest build of SeaMonkey ...
Comment 21•11 years ago
|
||
So, obviously some leak (~1 GB), can you save memory reports (about:memory page) from both old and new build with 5300 iframes and post them here?
Reporter | ||
Comment 22•11 years ago
|
||
I have already done from 2900 iframes only, dut diferrence in RAM alocation too - this is from old build
Reporter | ||
Comment 23•11 years ago
|
||
And from latest build 20130810003001
Comment 24•11 years ago
|
||
What is this file - C:/Users/Vlada/AppData/Roaming/Mozilla/SeaMonkey/Profiles/3wc0ad21.default/!Moje/Zbytek/www-lide-cz_hodnotit/Hotove/Links_25e.htm and why it is in your profile directory? That is file you are loading? But why it in profile dir then? And did you put it into Firefox profile dir while testing Firefox for leak?
Reporter | ||
Comment 25•11 years ago
|
||
Links_25e.htm is my "testing file" - concretely this with 2900 iframes and is (as my other "files with iframes") in subdirectory in my "profile directory" C:/Users/Vlada/AppData/Roaming/Mozilla/SeaMonkey/Profiles/3wc0ad21.default (I use these files and backup it with my profile ...) I open it from all builds SeaMonkey and ForeFox from this directory - i test now latest FireFox with "Links_25e.htm" (for compare) too and post results here ...
Reporter | ||
Comment 26•11 years ago
|
||
Latest FireFox with same file (5300 iframes) - open file normally (as oldest build of SeaMonkey), but use too more RAM, than oldest build of SeaMonkey...
Reporter | ||
Comment 27•11 years ago
|
||
FireFox with same file with 2900 iframes
Comment 28•11 years ago
|
||
(In reply to Sladky Vladimir from comment #27) > FireFox with same file with 2900 iframes We need two reports from FF, one before problem in SM arise, and second after
Reporter | ||
Comment 29•11 years ago
|
||
In FF no problem - only crashed to if too many iframes opened and i send these reports for compare with SM in same situation only ... Send report from FF near crash with 80000 iframes to, or from SM only ??? I don't understand - my english very bad... ;-(
Comment 30•11 years ago
|
||
The idea is to see how change affects FF to try to find what changed and why only SM affected. So, we need three about:memory reports from FF, one on 20130718 build, one on 20130719 build and last one on 20130720 build
Reporter | ||
Comment 31•11 years ago
|
||
I send about:memory reports (all with 2900 iframes - not crashed)from: 20130718 https://bugzilla.mozilla.org/attachment.cgi?id=788686 20130719 (this version not available) 20130810 https://bugzilla.mozilla.org/attachment.cgi?id=788687 Send too 20130720 (with 2900 iframes) or which versions ??? Canot direct compare sources from 20130718 or 20130719 (if available) and (first) AFFECTED 20130720 ???
Reporter | ||
Comment 32•11 years ago
|
||
In C:\Users\Vlada\AppData\Local\Mozilla\SeaMonkey\Profiles\3wc0ad21.default\safebrowsing\ maybe from 20130720 download (or create?) SM files "goog-*.*" and older builds "test-*.*" only ??? But if i disable in preferences "Safe Browsing" it is no use and problem persist :-(
Comment 33•11 years ago
|
||
Both good-* and test-* files should exist. The test-* files exist only so that tests that use: http://www.mozilla.org/firefox/its-a-trap.html and http://www.mozilla.org/firefox/its-an-attack.html will work.
Reporter | ||
Comment 34•11 years ago
|
||
Or use for tracking "ProcessMonitor" (what alocate RAM before SM read iframes etc.) ??? I test it with 80000 iframes, see how to SM open files, create and exit proceses, alocate RAM, stack if crashed and call crashreporter (in stack near crash see to nspr4.dll maybe not cause crash), but canot identify, who conretely reason of crash (with too many iframes), or alocate RAM before open iframes - any idea please ???
Comment 35•11 years ago
|
||
(In reply to Sladky Vladimir from comment #31) > I send about:memory reports (all with 2900 iframes - not crashed)from: Not in SeaMonkey, in Firefox this time, in http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2013-07-18-03-02-01-mozilla-central/firefox-25.0a1.en-US.win32.zip http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2013-07-19-03-02-04-mozilla-central/firefox-25.0a1.en-US.win32.zip http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2013-07-20-03-02-14-mozilla-central/firefox-25.0a1.en-US.win32.zip builds
Reporter | ||
Comment 36•11 years ago
|
||
Reporter | ||
Comment 37•11 years ago
|
||
Reporter | ||
Comment 38•11 years ago
|
||
Attachment #789167 -
Attachment is obsolete: true
Attachment #789169 -
Attachment is obsolete: true
Attachment #789168 -
Attachment is obsolete: true
Attachment #788638 -
Attachment is obsolete: true
Attachment #788639 -
Attachment is obsolete: true
Attachment #788692 -
Attachment is obsolete: true
Attachment #788693 -
Attachment is obsolete: true
Comment 39•11 years ago
|
||
No idea what to check next, I'll try at weekend to make a couple of builds with some patches rolled back, but don't know if all will be fine Nicholas, can you look at those two memory reports from SeaMonkey and give an advise what to check?
Reporter | ||
Comment 40•11 years ago
|
||
All FF (latest and before than 18. jul to) to wait little more time after all iframes loaded from www server (until "done" in Status line), but not alocated memory before - SM 0718 (and builds before) is fastest
Comment 41•11 years ago
|
||
So, first test build is out, let's see how it behaves, download link - http://www.cs.iptcom.net/debug/build1.zip
Reporter | ||
Comment 42•11 years ago
|
||
This is meanwhile best build and best result !!! 5000 iframes open suscefully and fast (not alocate any RAM before) and with 82000 iframes not crashed (only not responding after use 62% from my 8GB RAM - previous build crashed before used 50% RAM - see attachment) I test i an short time how many iframes now open witkout crash ...
Reporter | ||
Comment 43•11 years ago
|
||
If open more than 20000 iframes, SM not crashed, but only "not responding" (each time) after use exactly 62% of my 8GB RAM - see previous attachment with SM "display dialog" please ... I open 10000 iframex maximum - is plase possible open more iframes (if SM use more RAM) ???
Comment 44•11 years ago
|
||
It looks like I've disabled too much in order to get lower build time, but that build is not comparable to regular nightly, let's now try do the things properly: http://www.cs.iptcom.net/debug/build2.zip Also, there is no need in memory reports for now, just provide feedback (bad/good compared with last properly working build)
Reporter | ||
Comment 45•11 years ago
|
||
With 82000 iframes crashes in 56% memory usage: https://crash-stats.mozilla.com/report/index/90f2e55c-3a6d-49c6-aaa5-6d0c32130818
Comment 46•11 years ago
|
||
Test *normal* usage, compared to 0718 build, not edge cases
Reporter | ||
Comment 47•11 years ago
|
||
With 5000 iframes (="normal usage") working properly and fast (as build 0718) with 10000 iframes crashed (previous "build1" not crashed), but crash report now AVAILABLE !!!: https://crash-stats.mozilla.com/report/index/0fa1c707-8364-426d-937c-d6f482130818
Comment 48•11 years ago
|
||
> https://crash-stats.mozilla.com/report/index/0fa1c707-8364-426d-937c-d6f482130818
We don't seem to have any symbols for this crash report so it's pretty useless.
KaiRo any idea why? Perhaps this is an OOM?
Reporter | ||
Comment 49•11 years ago
|
||
Browse on Badoo.com with build2 https://crash-stats.mozilla.com/report/index/deb7b1aa-9b40-4402-9bb0-9d69f2130818
Comment 50•11 years ago
|
||
(In reply to Philip Chee from comment #48) > We don't seem to have any symbols for this crash report so it's pretty > useless. I suppose that because this is custom build Vladimir, test next two builds: http://www.cs.iptcom.net/debug/build3.zip http://www.cs.iptcom.net/debug/build_trunk.zip
Reporter | ||
Comment 51•11 years ago
|
||
build_trunk.zip is bad - alocate RAM before open iframes and with extreme 82000 iframes crashed shortly after alocate RAM build3.zip is O.K. - not alocate RAM before open iframes and working properly - crashed only with extreme 82000 iframes (63% RAM alocated)
Comment 52•11 years ago
|
||
New build to test http://www.cs.iptcom.net/debug/build4.zip Second is building now, but I'm going to sleep and will upload it at morning...
Comment 53•11 years ago
|
||
http://www.cs.iptcom.net/debug/build5.zip
Comment 54•11 years ago
|
||
(In reply to Philip Chee from comment #48) > > https://crash-stats.mozilla.com/report/index/0fa1c707-8364-426d-937c-d6f482130818 > We don't seem to have any symbols for this crash report so it's pretty > useless. > KaiRo any idea why? Perhaps this is an OOM? No idea, but I'd guess at OOM for sure.
Reporter | ||
Comment 55•11 years ago
|
||
build4.zip is O.K. - not alocate RAM before open iframes and working properly - crashed only with extreme 82000 iframes In build5.zip canot open local file (Ctrl+O, Open File dialog, open from command line NOT AVAILABLE), windows size (from localstore.rdf) is to smal. With "localstore.rdf" i have too problem (in all previous versions and long time) - if i in safe mode modify Sidebar (delete or edit any, or all items), close SM and run it in Save Mode, all (deleted or modified) items in sidebar be back - not remember settings of sidebar in localstore.rdf ...
Comment 56•11 years ago
|
||
That's strange, build 5 works fine locally, but anyway, current uploaded build: http://www.cs.iptcom.net/debug/build_139080.zip If second build finishes before I leave, it would be available at http://www.cs.iptcom.net/debug/build_139227.zip and at morning third would be at http://www.cs.iptcom.net/debug/build_139260.zip
Reporter | ||
Comment 57•11 years ago
|
||
build_139080.zip is very bad and i canot use it :-( 1) Canot open local file (Ctrl+O, Open File dialog, open from command line NOT AVAILABLE) 2) Bookmark Toolbar not available (all bookmarks on this toolbar hiden) 3) In context menu (right click) all items always visible 4) Right click + Ctrl not open links in new tab
Comment 58•11 years ago
|
||
It looks like something wrong with your system as I don't have any mentioned problems on either my test/build or home systems, so I suggest you to check today builds on other system/clean profile Second one will be available for download in 5 minutes...
Reporter | ||
Comment 59•11 years ago
|
||
With clean (new) profile with build_139080.zip same problems and with build_139227.zip too. Too not functional menu - Help/About SM, About Plugins, Tools/Add-ons Manager I test too this bulid in Windows XP in VirtualBox ...
Reporter | ||
Comment 60•11 years ago
|
||
In Windows XP build_139227.zip too not have bookmarks on Bookmark Toolbar. But other problems (1,3,4,menu) not exist and functional. But i needed use SM in Windows 8 64bit and builds build_139080.zip and build_139227.zip have here all the problems (1,2,3,4,main menu) ...
Comment 61•11 years ago
|
||
I just finished testing those three builds on my other server with Windows 2003, they all working completely fine, so I don't know from where your problem coming from. What antivirus are you using? I suggest you to test those build on separate completely clean system with integrated MS antivirus disabled, he is known to cause problems in other programs
Reporter | ||
Comment 62•11 years ago
|
||
I no use any antivirus and pravious builds (build4.zip) work properly ...
Reporter | ||
Comment 63•11 years ago
|
||
In latest build 20130821003001 (updated over "update service") i see to many errors: https://bugzilla.mozilla.org/show_bug.cgi?id=561450 in Source File: resource://gre/modules/Deprecated.jsm Line: 79 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Timestamp: 22. 8. 2013 21:48:42 Error: DEPRECATION WARNING: uriTypes is deprecated ans will be removed in a future version You may find more details about this deprecation at: https://bugzilla.mozilla.org/show_bug.cgi?id=561450 resource://gre/modules/PlacesUtils.jsm 212 null chrome://communicator/content/places/browserPlacesViews.js 298 PVB__createMenuItemForPlacesNode chrome://communicator/content/places/browserPlacesViews.js 361 PVB__insertNewItemToPopup chrome://communicator/content/places/browserPlacesViews.js 253 PVB__rebuildPopup chrome://communicator/content/places/browserPlacesViews.js 808 PVB__onPopupShowing chrome://communicator/content/places/browserPlacesViews.js 1602 PT__onPopupShowing chrome://communicator/content/places/browserPlacesViews.js 1060 PT_handleEvent chrome://global/content/bindings/button.xml 38 set_open chrome://communicator/content/places/browserPlacesViews.js 1645 PT__onMouseMove chrome://communicator/content/places/browserPlacesViews.js 1053 PT_handleEvent null 0 null Source File: resource://gre/modules/Deprecated.jsm Line: 79 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Timestamp: 22. 8. 2013 21:51:07 Error: DEPRECATION WARNING: nsIContentPrefService is deprecated. Please use nsIContentPrefService2 instead. You may find more details about this deprecation at: https://developer.mozilla.org/en-US/docs/XPCOM_Interface_Reference/nsIContentPrefService2 resource://gre/components/nsContentPrefService.js 1234 ContentPrefService__parseGroupParam resource://gre/components/nsContentPrefService.js 240 ContentPrefService_getPref chrome://communicator/content/viewZoomOverlay.js 201 FullZoom_onLocationChange chrome://navigator/content/nsBrowserStatusHandler.js 344 null chrome://navigator/content/tabbrowser.xml 844 notifyUrlBar chrome://navigator/content/tabbrowser.xml 841 updateUrlBar chrome://navigator/content/tabbrowser.xml 993 updateCurrentBrowser chrome://navigator/content/tabbrowser.xml 2765 onxblselect chrome://global/content/bindings/tabbox.xml 661 set_selectedIndex chrome://global/content/bindings/tabbox.xml 680 set_selectedPanel chrome://global/content/bindings/tabbox.xml 398 set_selectedIndex chrome://global/content/bindings/tabbox.xml 430 set_selectedItem chrome://global/content/bindings/tabbox.xml 475 _selectNewTab chrome://global/content/bindings/tabbox.xml 788 onxblmousedown null 0 null Source File: resource://gre/modules/Deprecated.jsm Line: 79
Comment 64•11 years ago
|
||
Those irrelevant...
Reporter | ||
Comment 65•11 years ago
|
||
Yesterday SM 3x crashed on Facebook, but i have opened (extreme) 120 tabs (al on Facebook) and crashed to if alocated 6o% RAM. I have idea - before run SM i have used 15% from my 8GB RAM. If crashed (with extreme 82000 iframes) too aloceated 60-62% RAM = (aproximately) 4GB. Canot crashed if SM adresing more than 4GB ??? Awailable to 64bit build of SM ??? (FF 64bit i not use - problems with my someone extensions)
Comment 66•11 years ago
|
||
Only unofficial release builds - https://docs.google.com/folderview?id=0BxHqn7o9vZBaZWlQZFd5TFRRS2M&tid=0BxHqn7o9vZBaQkpwcUNsbWNERHc
Reporter | ||
Comment 67•11 years ago
|
||
Reporter | ||
Comment 68•11 years ago
|
||
Reporter | ||
Comment 69•11 years ago
|
||
64Bit SM build 20130810142355 solve this problem !!! If open (extreme) 82000 iframes (all in 1 TAB or 19 files with aproximatelly 5000 iframes in 1 TAB) i mus SM cancel (workinkg more than 1 hours with pagefile), but 15000 iframes (in 1 TAB) now open SUSCEFULLY !!! (with 15000 iframes only too work long time with pagefile after no network activity, all iframes SUSCEFULLY opened, but SM meantime not responding) Is please (in safe mode) save any used memory - (temporary disabling cache, or history) or what possible (temporary) switch off ??? You please will too work on 64bit SM and too on newest builds (2.23) that this "unoficial" (older) 64bit 2.20 ???
Comment 70•11 years ago
|
||
(In reply to Sladky Vladimir from comment #69) [...] > Is please (in safe mode) save any used memory - (temporary disabling cache, > or history) or what possible (temporary) switch off ??? [...] Safe Mode disables all add-ons except the Default theme and, if you use one, your current Persona. IIUC it also disables userChrome.css and userContent.css, which, however, are not present by default. So depending on what you have added to SeaMonkey, and on whether you use ChatZilla, DOM Inspector and/or Venkman (the built-in extensions), the memory economy that Safe Mode gives you can vary between negligible and huge.
Reporter | ||
Comment 71•11 years ago
|
||
How to please run SM in safe mode (from *.bat file and with comand line "-safe-mode") directly - without manually "pres ENTER" ??? How to please detect in external program (writen in Delphi) if page in SM is opened completely ??? Or exist please add-on like "Open Multiple Locations" but open too local files ??? I find solution how to open (extremely) 82000 iframes from one file, or from more files, but automatically and with save memory (not use page file...) - thang You and sorry for O.T. in this thread ... :-(
Comment 72•11 years ago
|
||
So, a friend of mine tested last my builds in Windows 8, they run just fine without any problems, so problem either in your system or some additional things which you are not saying to us. I may make some other build with m-c revision lower than 139080, but only if my build server goes online on next week. And no, there is no (and will be no in foreseen future) x64 trunk builds...
Reporter | ||
Comment 73•11 years ago
|
||
At the moment i use 64 bit build 20130811132302 (without automatic update) - at the moment no problems (only add-on Mouse Gestures Redox "not paint", otherwise fully functional - this add-on ist too old, and not spupported, but for me better, than All-in-one Gestures). Now i will be test too your latest 32 bit build, but 64 bit is for me beter (use all of my 8GB RAM, and page file too) ...
Reporter | ||
Comment 74•11 years ago
|
||
I test latest 32 bit build 0831 - crashes with 4000 iframes only and alocate memory before open it - with (extreme) 82000 iframes crashed before alocate 50% of my memory only and i open sometime to much (extreme) TABs - SM 32 bit crashes too if alocated 50% of my memory :-( 64 Bit is for me better and not crashes with 82000 iframes - but alocated all of my 8GB RAM + aproximatelly 8GB page file - is more stable ... What is "m-c revision" please ???
Comment 75•11 years ago
|
||
(In reply to Sladky Vladimir from comment #74) [...] > What is "m-c revision" please ??? m-c is short for mozilla-central. Revisions are usually referred to by a changeset ID in hex: IIUC, rev 139080 means changeset http://hg.mozilla.org/mozilla-central/rev/d428ab19f2c7 dated 18 July for bug 886508
Comment 76•11 years ago
|
||
(In reply to Sladky Vladimir from comment #73) > At the moment i use 64 bit build 20130811132302 (without automatic update) > - at the moment no problems (only add-on Mouse Gestures Redox "not paint", > otherwise fully functional - this add-on ist too old, and not spupported, > but for me better, than All-in-one Gestures). > Now i will be test too your latest 32 bit build, but 64 bit is for me beter > (use all of my 8GB RAM, and page file too) ... If it's a Windows build (as your comment #0, posted with a 32-bit build on a 64-bit Windows OS, seems to indicate), I don't know where you got it, unless you compiled it yourself. SeaMonkey builds are normally made on Mozilla machines for Universal-build Mac 32/64, Linux32, Linux64 ("unofficial" but still Mozilla-built), and Win32. The 32-bit builds run on 64-bit hardware and OSes if you've got the necessary underlying software (such as 32-bit system libraries) but of course not the opposite. As Phoenix said in comment #72, no 64-bit-only Windows versions of SeaMonkey in the foreseeable future.
Reporter | ||
Comment 77•11 years ago
|
||
My comment in (old) 32 bit Build ID: 20130621003008 if with latest build problems and i mus used old build ... 64 bit i use from https://bugzilla.mozilla.org/show_bug.cgi?id=901370#c66 - before 64 bit builds SM i dont known for me ... The 32-bit builds run on my 64-bit hardware, but not used all memory and often crashed ... How to please (concretelly) i compile 64 bit builds yourself and where sources please ?
Reporter | ||
Comment 78•11 years ago
|
||
This is latest sources ? http://hg.mozilla.org/mozilla-central/file/b6c29e434519 What i needed for compile it in 64 bit please ???
Comment 79•11 years ago
|
||
Nope, you need http://hg.mozilla.org/comm-central/, and for building x64 you can look here - http://www.htguard.info/ or here - http://forum.moztw.org/viewtopic.php?f=43&t=20467 (Chinese)
Reporter | ||
Comment 80•11 years ago
|
||
What is please this error with "targeting i386 on 64 bit computer" ??? checking for make... /local/bin/make checking for X... no checking that static assertion macros used in autoconf tests work... yes checking for 64-bit OS... yes configure: error: You are targeting i386 but using the 64-bit compiler. I use "start-msvc11-x64.bat", maybe canot call "vcvars64.bat" but i have Visual Studio 2012 Ultimate and not Expres ? How to fix it please ??? This is my mozconfig for SeaMonkey: mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/suite-opt ac_add_options --enable-application=suite ac_add_options --target=x86_64-pc-mingw32 ac_add_options --host=x86_64-pc-mingw32 # Set the number after -j to the number of cores in your machine mk_add_options MOZ_MAKE_FLAGS="-j4" ac_add_options --enable-optimize ac_add_options --disable-debug # add the following if you did NOT install the DirectX SDK ac_add_options --disable-angle ac_add_options --disable-gamepad HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH Vlada@PC1 /c/dev/mozilla-central $ ./build/pymake/make.py -f client.mk configure make.py[0]: Entering directory 'c:\dev\mozilla-central' c:\dev\mozilla-central\client.mk:303:0$ python c:/dev/mozilla-central/config/pythonpath.py -I c:/dev/mozilla-central/tes ting/mozbase/mozfile \ c:/dev/mozilla-central/python/mozbuild/mozbuild/controller/clobber.py c:/dev/mozilla-central obj-i686-pc-mingw32 Clobber not needed. TEST-PASS | check-sync-dirs.py | c:\dev\mozilla-central\js\src\build <= c:\dev\mozilla-central\build Generating c:/dev/mozilla-central/configure using autoconf c:\dev\mozilla-central\client.mk:274:0$ cd c:/dev/mozilla-central; /local/bin/autoconf-2.13 TEST-PASS | check-sync-dirs.py | c:\dev\mozilla-central\js\src\build <= c:\dev\mozilla-central\build Generating c:/dev/mozilla-central/js/src/configure using autoconf c:\dev\mozilla-central\client.mk:274:0$ cd c:/dev/mozilla-central/js/src; /local/bin/autoconf-2.13 c:\dev\mozilla-central\config\makefiles\autotargets.mk:59:0$ pymake.builtins mkdir -p "obj-i686-pc-mingw32/" c:\dev\mozilla-central\client.mk:317:0$ cp obj-i686-pc-mingw32/.mozconfig cp: missing destination file operand after `obj-i686-pc-mingw32/.mozconfig' Try `cp --help' for more information. cd obj-i686-pc-mingw32 c:/dev/mozilla-central/configure creating cache ./config.cache checking host system type... i686-pc-mingw32 checking target system type... i686-pc-mingw32 checking build system type... i686-pc-mingw32 checking for mawk... no checking for gawk... gawk checking for python2.7... /c/mozilla-build/python/python2.7 Creating Python environment New python executable in c:/dev/mozilla-central/obj-i686-pc-mingw32/_virtualenv\Scripts\python2.7.exe Also creating executable in c:/dev/mozilla-central/obj-i686-pc-mingw32/_virtualenv\Scripts\python.exe Installing setuptools................done. Installing pip...................done. running build_ext building '_psutil_mswindows' extension error: Unable to find vcvarsall.bat Error processing command. Ignoring because optional. (optional:setup.py:python/psutil:build_ext:--inplace) checking Python environment is Mozilla virtualenv... yes checking for perl5... no checking for perl... /bin/perl checking for gcc... cl checking whether the C compiler (cl ) works... yes checking whether the C compiler (cl ) is a cross-compiler... no checking whether we are using GNU C... no checking whether cl accepts -g... no checking for c++... cl checking whether the C++ compiler (cl ) works... yes checking whether the C++ compiler (cl ) is a cross-compiler... no checking whether we are using GNU C++... no checking whether cl accepts -g... no checking for ranlib... : checking for ml... no checking for as... no checking for ar... no checking for ld... link checking for strip... no checking for windres... no checking for midl... midl checking for midl flags... none needed checking for std::_Throw... no checking for overridable _RAISE... yes checking for winsdkver.h... yes checking for highest Windows version supported by this SDK... 0x06020000 checking for Windows SDK being recent enough... yes checking how to run the C preprocessor... cl -E -nologo checking how to run the C++ preprocessor... cl -TP -E -nologo checking for a BSD compatible install... /bin/install -c checking whether ln -s works... no checking for minimum required perl version >= 5.006... 5.006001 checking for full perl installation... yes checking for doxygen... : checking for autoconf... /bin/autoconf checking for unzip... /c/mozilla-build/info-zip/unzip checking for zip... /c/mozilla-build/info-zip/zip checking for xargs... /bin/xargs checking for rpmbuild... : checking compiler version... Microsoft (R) C/C++ Optimizing Compiler Version 17.00.50727.1 for x64 Copyright (C) Microsoft Corporation. All rights reserved. cl : Command line warning D9002 : ignoring unknown option '--version' cl : Command line error D8003 : missing source filename checking for make... /local/bin/make checking for X... no checking that static assertion macros used in autoconf tests work... yes checking for 64-bit OS... yes configure: error: You are targeting i386 but using the 64-bit compiler. ------ config.log ------ #define CONFIGURE_STATIC_ASSERT_IMPL2(condition, line) typedef int static_assert_line_##line[(condition) ? 1 : -1] int main() { CONFIGURE_STATIC_ASSERT(0) ; return 0; } configure:6753: cl -c -TP -nologo conftest.C 1>&5 conftest.C configure:6770: cl -c -TP -nologo conftest.C 1>&5 conftest.C configure(6770) : error C2118: negative subscript configure: failed program was: #line 6763 "configure" #include "confdefs.h" #define CONFIGURE_STATIC_ASSERT(condition) CONFIGURE_STATIC_ASSERT_IMPL(condition, __LINE__) #define CONFIGURE_STATIC_ASSERT_IMPL(condition, line) CONFIGURE_STATIC_ASSERT_IMPL2(condition, line) #define CONFIGURE_STATIC_ASSERT_IMPL2(condition, line) typedef int static_assert_line_##line[(condition) ? 1 : -1] int main() { CONFIGURE_STATIC_ASSERT(0) ; return 0; } configure:7752: checking for 64-bit OS configure:7761: cl -c -TC -nologo conftest.c 1>&5 conftest.c configure: error: You are targeting i386 but using the 64-bit compiler. *** Fix above errors and then restart with "c:/mozilla-build/python/python.exe c:/dev/mozilla-central/buil d/pymake/pymake/../make.py -f client.mk build" c:\dev\mozilla-central\client.mk:322:0: command 'cd obj-i686-pc-mingw32 && MAKE="c:/mozilla-build/python/python.exe c:/ dev/mozilla-central/build/pymake/pymake/../make.py" c:/dev/mozilla-central/configure \ || ( echo "*** Fix above errors and then restart with\ \"c:/mozilla-build/python/python.exe c:/dev/mozilla-central/build/pymake/pymake/../make.py -f client.mk b uild\"" && exit 1 )' failed, return code 1 Vlada@PC1 /c/dev/mozilla-central $
Reporter | ||
Comment 81•11 years ago
|
||
FireFox (only 32 bit] now i build suscefully, but SeaMonkey not :-( What problem please if 'mapix.h not exist ? c:\users\vlada\comm-central\mailnews\addrbook\src\nsAbWinHelper.h(9) : fatal error C1083: Cannot open include file: 'mapix.h': No such file or directory
Reporter | ||
Comment 82•11 years ago
|
||
I now successfully compiled (and testing) build 20130904113630 in 64Bit (compiled and omptimized for my AMD64 VIZ Trinity), but always alocate memory before open files with iframes (too 5000 only). I mus use old build 20130718003001 or 20130811 (64Bit) and the newest builds not usable for me... :-( Is any solution of this problem yet (with alocate memory before open files) please ? Thank You
Comment 83•11 years ago
|
||
Well, as you now able to make test builds by yourself, you can narrow problem to one changeset. Start cmd.exe, go to comm-central source folder and return it to 19 Jul state with hg revert --revision 12779 command, enter mozilla subfolder, run hg revert --revision 139080 and when it finishes make a test build. It should be "bad" for you, if it is, go down from 139080 with 10 steps at once (hg revert --revision 139070, hg revert --revision 139060, etc) make builds and test them until you find first working build. Then just go up with 1 step till you find first "bad" build and post it's revision here.
Comment 84•11 years ago
|
||
(In reply to Phoenix from comment #83) > Well, as you now able to make test builds by yourself, you can narrow > problem to one changeset. > Start cmd.exe, go to comm-central source folder and return it to 19 Jul > state with > hg revert --revision 12779 > command, enter mozilla subfolder, run > hg revert --revision 139080 > and when it finishes make a test build. It should be "bad" for you, if it > is, go down from 139080 with 10 steps at once (hg revert --revision 139070, > hg revert --revision 139060, etc) make builds and test them until you find > first working build. Then just go up with 1 step till you find first "bad" > build and post it's revision here. To set the working directory to what it was at some specific changeset it's not "hg revert" but "hg update" "hg revert" restores one or more files to a certain state; it must be followed by a commit. "hg update" sets your whole hg clone's “working directory” (i.e., the directories and files you'll use to compile, not the Mercurial metadata) to the state corresponding to a certain revision. It does not need a commit because it changes nothing to the network of changesets present in the clone. See "hg help revert" and "hg help update".
Reporter | ||
Comment 85•11 years ago
|
||
Yes, now i able make test builds yourself (in 64Bit for my AMD64 Trinity)... Problem with crasch in 32Bit version and usage 4GB RAM only in 64Bit version now solved - i test this 64bit build, open 350 TABs on Facebook - alocate full 8GB RAM and SM now not crasched and test with local file (content 15000 iframes "only") now too not crashed - alocate full 8GB RAM + 20% page file and only alocate RAM too many minutes befote connect to Internet, but now not crashed... I test only compile with jemalloc disabled and enabled - with enabled is really better, but problem with alocate ram before connect not solved. I try compile this old build with "hg update --revision 12779" now ...
Reporter | ||
Comment 86•11 years ago
|
||
In uour previous test build2.zip and build4.zip (only) too not problem with RAM alocate before connect ...
Reporter | ||
Comment 87•11 years ago
|
||
I have problem - how to please (concretely) set to build 139080 ? Vlada@PC1 ~/comm-central $ hg update --rev 12779 922 files updated, 0 files merged, 25 files removed, 0 files unresolved Vlada@PC1 ~/comm-central $ hg update --rev 139080 abort: unknown revision '139080'! Or $ hg revert --rev 12779 --all and after update ??? 12779 and 12780 exist, but 139080 not exist, 139055 not exist... ;-(
Reporter | ||
Comment 88•11 years ago
|
||
Latest 12993 exist ???
Comment 89•11 years ago
|
||
*enter mozilla subfolder*
Reporter | ||
Comment 90•11 years ago
|
||
Now i canot compile builds (approximatelly) older than 145500 (i not try revizion accuratelly - is night time) - e.g. 145500, 145746 and latest compile succesfully, but 145200 or 140000 canot compile - see attachemt please - error: c:\Users\Vlada\comm-central\ldap\xpcom\src\moz.build The error was triggered on line 37 of this file: EXPORT_LIBRARY = True
Updated•11 years ago
|
Summary: Canot open 5000 iframes from local file (approximately from 20. Jul) → Cannot open 5000 iframes from local file (approximately from 20. Jul)
Reporter | ||
Comment 91•11 years ago
|
||
And now i 3 days canot nothing at all compile - each revisions have any (various) errors - e.g. attachment from latest (actual) revizion after "python client.py checkout" and after new (complete) clone from clone http://hg.mozilla.org/comm-central/ too :-( Any solution please ?
Comment 92•11 years ago
|
||
Compile 32 bit version for testing
Reporter | ||
Comment 93•11 years ago
|
||
Latest build in 32Bit same Error a too canot compile from 4. September where i use in 64Bit This is from latest 32Bit: c:/Users/Vlada/comm-central/mozilla/nsprpub/pr/src/threads/prtpd.c(146) : warning C4018: '>=' : signed/unsigned mismatch make.py[7]: Leaving directory 'c:\Users\Vlada\comm-central\objdir-sm-release\mozilla\nsprpub\pr\src\threads' make.py[7]: Entering directory 'c:\Users\Vlada\comm-central\objdir-sm-release\mozilla\nsprpub\pr\src' Error executing command ../../config/./now [Error 2] SystÚm nem¨×e nalÚzt uvedenř soubor Error executing command ../../config/./now [Error 2] SystÚm nem¨×e nalÚzt uvedenř soubor LINK : fatal error LNK1104: cannot open file 'mozcrt.lib'
Comment 94•11 years ago
|
||
Erase objdir-sm-release
Reporter | ||
Comment 95•11 years ago
|
||
Latest build in 32Bit same Error a too canot compile from 4. September where i use in 64Bit This is from latest 32Bit: c:/Users/Vlada/comm-central/mozilla/nsprpub/pr/src/threads/prtpd.c(146) : warning C4018: '>=' : signed/unsigned mismatch make.py[7]: Leaving directory 'c:\Users\Vlada\comm-central\objdir-sm-release\mozilla\nsprpub\pr\src\threads' make.py[7]: Entering directory 'c:\Users\Vlada\comm-central\objdir-sm-release\mozilla\nsprpub\pr\src' Error executing command ../../config/./now [Error 2] SystÚm nem¨×e nalÚzt uvedenř soubor Error executing command ../../config/./now [Error 2] SystÚm nem¨×e nalÚzt uvedenř soubor LINK : fatal error LNK1104: cannot open file 'mozcrt.lib'
Reporter | ||
Comment 96•11 years ago
|
||
objdir-sm-release erased, compile to 32Bit only with only: ac_add_options --enable-application=suite mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/objdir-sm-release mk_add_options MOZ_MAKE_FLAGS="-j4" and alwais this error: c:/Users/Vlada/comm-central/mozilla/other-licenses/snappy/src/snappy.cc(962) : warning C4018: '<=' : signed/unsigned mismatch c:\users\vlada\comm-central\mozilla\other-licenses\snappy\src\snappy-stubs-internal.h(134) : warning C4722: 'snappy::LogMessageCrash::~LogMessageCrash' : destructor never returns, potential memory leak make.py[3]: Leaving directory 'c:\Users\Vlada\comm-central\objdir-sm-release\mozilla\other-licenses/snappy' make.py[3]: Entering directory 'c:\Users\Vlada\comm-central\objdir-sm-release\mozilla\../mozilla/xpfe/components/autocomplete' make.py[3]: Leaving directory 'c:\Users\Vlada\comm-central\objdir-sm-release\mozilla\../mozilla/xpfe/components/autocomplete' make.py[3]: Entering directory 'c:\Users\Vlada\comm-central\objdir-sm-release\mozilla\../ldap/xpcom' No rule to make target 'compile' needed by ['<command-line>', 'compile']
Reporter | ||
Comment 97•11 years ago
|
||
I canot compile no any versions of SeaMonkey from 4. september Today (successfully) compile latest version in 64Bit only and with "ac_add_options --enable-extensions=default,-venkman" only (otherwise several errors and canot compile) I today (in 32bit and 64bit too) tri: hg update --rev 145746 and compile too successfully but older versions e.g. hg update --rev 139080 canot compile - se attachment please ... No any chance find "affected build" from 20. jul and resolve bug with "memory alocation before connect" please ??? ... :-(
Reporter | ||
Comment 98•11 years ago
|
||
Is please any news in (slow) "memory alocation before connect" ??? I mus daily twice use old version SM (new is very slow), older revisons (fom jul) i alwais canot compile and this "bug" https://bugzilla.mozilla.org/show_bug.cgi?id=916145 is marked as "invalid" ... :-(
Comment 99•11 years ago
|
||
http://www.cs.iptcom.net/debug/rv139000.7z http://www.cs.iptcom.net/debug/rv139040.7z http://www.cs.iptcom.net/debug/rv139080.7z Don't have any problems with building them...
Reporter | ||
Comment 100•11 years ago
|
||
All 3 builds affected
Comment 101•11 years ago
|
||
http://www.cs.iptcom.net/debug/rv138976.7z http://www.cs.iptcom.net/debug/rv138988.7z
Reporter | ||
Comment 102•11 years ago
|
||
All 2 builds affected
Comment 103•11 years ago
|
||
http://www.cs.iptcom.net/debug/rv138950.7z
Reporter | ||
Comment 104•11 years ago
|
||
Affected
Comment 105•11 years ago
|
||
http://www.cs.iptcom.net/debug/rv138850.7z http://www.cs.iptcom.net/debug/rv138900.7z
Reporter | ||
Comment 106•11 years ago
|
||
All 2 builds affected
Comment 107•11 years ago
|
||
http://www.cs.iptcom.net/debug/rv138846.7z
Reporter | ||
Comment 108•11 years ago
|
||
Build 138846 is O.K. - not affected
Comment 109•11 years ago
|
||
http://www.cs.iptcom.net/debug/rv138846-12772.7z http://www.cs.iptcom.net/debug/rv138846-12775.7z
Reporter | ||
Comment 110•11 years ago
|
||
All 2 builds O.K. - not affected
Comment 111•11 years ago
|
||
http://www.cs.iptcom.net/debug/rv138846-12777.7z http://www.cs.iptcom.net/debug/rv138846-12779.7z
Reporter | ||
Comment 112•11 years ago
|
||
All 2 builds affected
Comment 113•11 years ago
|
||
http://www.cs.iptcom.net/debug/rv138846-12776.7z
Reporter | ||
Comment 114•11 years ago
|
||
O.K. - not affected
Comment 115•11 years ago
|
||
So, then the reason should be Bug 886990. Neil, any ideas, why is this happened?
Comment 116•11 years ago
|
||
Well, smaug says that that patch shouldn't cause a leak... If I've understood correctly, 2.22 crashes if you have about 3000 iframes but is OK with 2000? Do these iframes have to be in the same page or does it crash if you have 3000 iframes split across 3 tabs (or windows) of 1000 iframes each? Once you know that opening a certain number of tabs (or windows) of 1000 iframes each makes it crash, does the crash go away if you close older tabs (or windows) as you go, so that you never have more than two tabs (or windows) open at once? (I say tabs or windows because you may find that the behaviour differs.) What sort of content is returned in these frames? Are they roughly identical? If so, can you attach an anonymised version of the page?
Reporter | ||
Comment 117•11 years ago
|
||
Bug with crasch now solved - i compile SM to 64Bit a now i use all off my 8GB without crasch - before compile to 64Bit use only 4GB RAM and crashed... (in 32Bit SM crash too if open "only" 500 tabs on Facebook and in 64Bit SM not crashed...) Now i have trouble if open 10000 iframes from file - not crashed, but many minutes "alocate RAM before connect" - in older builds from 18. Jul this problem not exist ...
Comment 118•11 years ago
|
||
(In reply to Sladky Vladimir from comment #117) > Bug with crasch now solved - i compile SM to 64Bit a now i use all off my > 8GB without crasch That's not an ideal solution, not only from the point of view of the "many minutes allocate RAM" but also it would be nice if we can find a way to stop 32-bit SeaMonkey from crashing. > (in 32Bit SM crash too if open "only" 500 tabs on Facebook and in 64Bit SM > not crashed...) I don't have Facebook either but this might mean that we can find a memory-hungry page that we can use for testing to try and identify the problem.
Reporter | ||
Comment 119•11 years ago
|
||
(In reply to neil@parkwaycc.co.uk from comment #118) > That's not an ideal solution, not only from the point of view of the "many > minutes allocate RAM" but also it would be nice if we can find a way to stop > 32-bit SeaMonkey from crashing. > > (in 32Bit SM crash too if open "only" 500 tabs on Facebook and in 64Bit SM > > not crashed...) > I don't have Facebook either but this might mean that we can find a > memory-hungry page that we can use for testing to try and identify the > problem. Not memory-hungry (affected and not affected build uses approximately same amount of RAM), but not affected build open page with many iframes directly (promptly) and afected build before open it alocate RAM many menutes and to work with RAM (many minutes) after open it... Not problem on this bug from Phoenix please ? https://bugzilla.mozilla.org/show_bug.cgi?id=886990 On my Windows 8 64Bit with 8GB RAM crashed in 62Bit SM all pages which alocate more than 4GB RAM and for testing not use only Facebook, but suffice open many (e.g. 2000) TABs on any other web pages. In 64Bit SM i test open 2500 TABs, normaly use all of my 8GB RAM and page file too and not crashed...
Comment 120•11 years ago
|
||
(In reply to Phoenix from comment #115) > So, then the reason should be Bug 886990. Neil, any ideas, why is this > happened? That password manager bug? Hm, Facebook obviously uses passwords, and so do many sites nowadays (including Bugzilla for that matter). I suppose it wouldn't be easy to try and find (or construct) some page with iframes but no passwords, to see if it can be opened with no crash in 32-bit SeaMonkey, even with an enormous number of iframes?
Reporter | ||
Comment 121•11 years ago
|
||
My test pages with 10000 (and more) iframes too uses passwords (and cookies) and 2500 tabs opened in SM64 (without crash) too opened on pages with passwords.
Reporter | ||
Updated•9 years ago
|
Status: UNCONFIRMED → RESOLVED
Closed: 9 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•