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)

Product:
SeaMonkey
Component:
General
Version:
SeaMonkey 2.22 Branch
Platform:
x86_64
Windows 8
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: vlposta, Unassigned)

Details

Attachments

(11 files, 8 obsolete files)

SeaMonkey_!New_5300_no_Crash.gif
144.28 KB, image/gif
Details
SeaMonkey_Old_5300_no_Crash.gif
146.94 KB, image/gif
Details
memory-old.json.gz
411.22 KB, application/octet-stream
Details
memory-new.json.gz
421.98 KB, application/octet-stream
Details
82500_iframes.gif
163.85 KB, image/gif
Details
10000_iframes.json.gz
1.36 MB, application/octet-stream
Details
64Bit solve this problem !!! (82000 iframes in 19 TABs)
173.46 KB, image/gif
Details
64Bit solve this problem !!! (15000 iframes in 1 TAB)
173.75 KB, image/gif
Details
EXPORT_LIBRARY_Error.txt
10.77 KB, text/plain
Details
mozcrt_ERROR.txt
9.33 KB, text/plain
Details
I canot compile rev. 139080
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?
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 ???
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... :-(
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
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\*.*
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%)
Can you post those crash ids from about:crashes?
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
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
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?
I now download Rammap tool - what interesting you concretely and how to use it for SeaMonkey only please ?
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
Attached image SeaMonkey.gif near before crashes (obsolete) — 
Open file with 80000 iframes (i have 8GB RAM), and make scereenschot near before SeaMonkey crashes - after crashes, process SeaMonkey in VMMap not awailable...
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 ...
Attached image SeaMonkey_!New_80000_before_Crash.gif (obsolete) — 
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
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...)
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 ...
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 ...
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?
Attached file memory-old.json.gz — 
I have already done from 2900 iframes only, dut diferrence in RAM alocation too

- this is from old build
Attached file memory-new.json.gz — 
And from latest build 20130810003001
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?
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 ...
Attached image FireFox_5300_no_Crash.gif (obsolete) — 
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...
Attached file memory-FireFox_2900.json.gz (obsolete) — 
FireFox with same file with 2900 iframes
(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
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... ;-(
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
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 ???
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 :-(
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.
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 ???
Attached file FF18.json.gz (obsolete) — 

    
    

    
  

      
      
      
      

        Attached file
          
        FF19.json.gz (obsolete)
        — 
      

    


  

    
    

    
  

      
      
      
      

        Attached file
          
        FF20.json.gz (obsolete)
        — 
      

    


  

    
  

        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

    
    

    
  
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?

    
    

    
  
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

    
    

    
  
So, first test build is out, let's see how it behaves, download link - http://www.cs.iptcom.net/debug/build1.zip

    
    

    
  

      
      
      
      

        Attached image
          
        82500_iframes.gif
        — 
      

    


  
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 ...

    
    

    
  

      
      
      
      

        Attached file
          
        10000_iframes.json.gz
        — 
      

    


  
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) ???

    
    

    
  
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)

    
    

    
  
With 82000 iframes crashes in 56% memory usage:
https://crash-stats.mozilla.com/report/index/90f2e55c-3a6d-49c6-aaa5-6d0c32130818

    
    

    
  
Test *normal* usage, compared to 0718 build, not edge cases

    
    

    
  
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

    
    

    
  
> 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?

    
    

    
  
(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

    
    

    
  
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)

    
    

    
  
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...

    
    

    
  
(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.

    
    

    
  
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 ...

    
    

    
  
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

    
    

    
  
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

    
    

    
  
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...

    
    

    
  
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 ...

    
    

    
  
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) ...

    
    

    
  
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

    
    

    
  
I no use any antivirus and pravious builds (build4.zip) work properly ...

    
    

    
  
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

    
    

    
  
Those irrelevant...

    
    

    
  
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)

    
    

    
  
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 ???

    
    

    
  
(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.

    
    

    
  
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 ... :-(

    
    

    
  
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...

    
    

    
  
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) ...

    
    

    
  
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 ???

    
    

    
  
(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

    
    

    
  
(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.

    
    

    
  
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 ?

    
    

    
  
This is latest sources ?

http://hg.mozilla.org/mozilla-central/file/b6c29e434519

What i needed for compile it in 64 bit please ???

    
    

    
  
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)

    
    

    
  
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
$

    
    

    
  
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

    
    

    
  
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

    
    

    
  
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.

    
    

    
  
(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".

    
    

    
  
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 ...

    
    

    
  
In uour previous test build2.zip and build4.zip (only) too not problem with RAM alocate before connect ...

    
    

    
  
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... ;-(

    
    

    
  
Latest 12993 exist ???

    
    

    
  
*enter mozilla subfolder*

    
    

    
  


  
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
Summary: Canot open 5000 iframes from local file (approximately from 20. Jul) → Cannot open 5000 iframes from local file (approximately from 20. Jul)

    
    

    
  

      
      
      
      

        Attached file
          
        mozcrt_ERROR.txt
        — 
      

    


  
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 ?

    
    

    
  
Compile 32 bit version for testing

    
    

    
  
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'

    
    

    
  
Erase objdir-sm-release

    
    

    
  
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'

    
    

    
  
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']

    
    

    
  


  
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 ??? ... :-(

    
    

    
  
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" ... :-(

    
    

    
  
All 3 builds affected

    
    

    
  
All 2 builds affected

    
    

    
  
Affected

    
    

    
  
All 2 builds affected

    
    

    
  
Build 138846 is O.K. - not affected

    
    

    
  
All 2 builds O.K. - not affected

    
    

    
  
All 2 builds affected

    
    

    
  
O.K. - not affected

    
    

    
  
So, then the reason should be Bug 886990. Neil, any ideas, why is this happened?

    
    

    
  
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?

    
    

    
  
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 ...

    
    

    
  
(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.

    
    

    
  
(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...

    
    

    
  
(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?

    
    

    
  
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.

    
  
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.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: