when using loader version 1.7.0.0 of 2012.FEB.17 one can get wild CPU/RAM consumption in certain pages.
this is fully documented in mozilla bugzilla report:
New: Run-Command (Dec 2, 2024), Platform 29.5.3 (Jun 27, 2024)
1,100+ portable packages, 1.1 billion downloads
No Ads Nov/Dec!, Please donate today
Visit the Community page
Join our forums
Subscribe to our email newsletter
Subscribe with RSS
Follow us on Facebook
Follow us on LinkedIn
Follow us on Twitter
Follow us on Mastodon
Follow us on BlueSky
SeaMonkey within SeaMonkey Portable is completely unaltered. The launcher (loader as you call it) simply calls SeaMonkey using documented command line calls using the bundled profile as a default. It then does nothing at all while SeaMonkey is running except wait for it to finish... anything SeaMonkey is doing, it is doing it on its own without interference from us. So, calling SeaMonkey from the command line from the same location using the same options (pointing it to the portable profile) will yield the same results. Incidentally, ensure it is not your antivirus causing the issues. Some antivirus apps act strangely when one EXE calls another.
I tested the URL you say caused problems in SeaMonkey Portable 2.11 on Windows 7 x64 and it came right up without issue.
Sometimes, the impossible can become possible, if you're awesome!
i believe i understand how the app works, it is just that there seems to be something happening unique to your app ... not SM (i.e., i concur that the SM called by the portable app is just a current version).
if you take a look at my events/comments/observations page i think you will see what i mean:
https://bugzilla.mozilla.org/attachment.cgi?id=647995
of course, the full bug report is available at the link in my original report, supra.
as you will see, running either your app or SM with the CLI '-profile' addr will both yield a bad result. however, running your app and restarting through the menu "Help --> Restart with Add-ons Disabled" will clear the problem. please note two things, though:
1.) the SM app is restarted by the portable app without any CLI options at all. thus, one might conclude that it is restarted knowing something from the environment inherited from the portable app and that the restart is not merely disabling the add-ons. NOTE: a regular copy of SM works just fine with all of the same add-ons enabled, so the add-ons really have nothing to do with anything from what i have experienced.
2.) the new PID of the restarted SM references your original app as the parent even though it will (normally) end up being parent-less. although it seems your app is supposed to kill itself, this does not always happen and it sometime stays in existence, but without any child association.
so, i guess the real question is why does the restarted SM without the portable app as a parent work while the portable app does not. is there something in the profile that is unique to the portable app that can cause this? if there are portable app-specific profile items, are they getting ignored in the restart and that is the reason SM will work at that time?
lastly, your comment seems to indicate that the portable app should be totally quiescent and merely waiting for the SM app to "INT 20" so that it can exit too. my observation is that the CPU activity of the portable app is nearly continuous, although at a very low utilization (~= 1%) and with no apparent disk/network I/O. so, the portable app must be doing something. perhaps you could let me know about this as well.
i really appreciate being able to call on your expertise so that we can clear up whatever is happening.
I'm still unsure what exactly your issue is. If I fire up a clean install of SeaMonkey Portable, load the URL, it works just fine. If I then restart SeaMonkey using Help - Restart With Addons disabled, it again loads just fine. No differences. And it's using about 44MB of RAM. And the SeaMonkeyPortable.exe launcher correctly waits around to clean up after SeaMonkey when it exits. It sits around polling to ensure it closes and then waits to ensure it didn't restart, which is why it sites around using 0.01% CPU.
Please start with a fresh copy (completely clean) of SeaMonkey Portable and disable anvir to ensure it is not interfering. Also, I don't know what supra is.
Sometimes, the impossible can become possible, if you're awesome!
In this case, it refers to the link in the original post.
Previously known as kAlug.
Ah ok. I didn't think he was referring to an old Toyota.
Sometimes, the impossible can become possible, if you're awesome!
i was using portable SM 1.7.0.0 (2012.FEB), the profile now in use, and SM 2.10. i have been using the portable app route since SM 2.7.2 (my last update of SM as a stand-alone app) and have utilized similar links on the site in question throughout the history of using the portable with no problems through SM 2.10.
to parallel the updating, i took the stand-alone SM through each major update using the last minor version from 2.7.2 to 2.11 and tested this link at each step and there were never any problems.
i took your suggestion re 'anvir' and observed that it has no affect running or not on the portable problem.
i downloaded the current 1.7.3.0 portable SM bundle and installed it in a new directory. i re-named the *.html and *.exe in the original portable directory and copied in their replacements.
STRANGELY: the executable is somehow wired into the directory of its installation since it started the SM/profile in that directory tree instead of what i expected would happen by the use of a relative call in the directory it was in. to circumvent this, i closed the SM tree and re-named the new installation directory. then, the new executable in the original portable directory did what one would expect and ran with the local SM app and profile.
unfortunately, nothing has changed since the problem still exists!
issue recap:
1.) portable 1.7.0.0 worked through SM 2.10 w/ the orig profile
2.) portable 1.7.0.0 does not work with SM 2.11 w/ the orig profile
3.) portable 1.7.0.0 does work with SM 2.11 w/ the orig profile when using the help menu restart w/o extensions
4.) portable 1.7.3.0 does not work with SM 2.11 w/ the orig profile
5.) portable 1.7.3.0 does work with SM 2.11 w/ the orig profile when using the help menu restart w/o extensions
6.) SM 2.11 under the portable's 'App' directory does not work if started with the CLI "-profile" option pointing to the orig portable profile
7.) when the portable restarts SM from the help menu it sometimes kills itself and sometimes does not
8.) SM stand-alone works in all versions from 2.7 through 2.11
to us non-programmers it appears that a profile issue has arisen since SM 2.11 that was previously ignored or did not, at least, interfere. the extensions do not matter, since the stand-alone SM works with all of the portable's extensions. however, when the portable usage encounters a problem and is restarted using the help menu option w/o extensions; something is being "cleared" since SM then works fine.
detailed observations and event logs are available at the bugzilla link i previously posted.
I was asking you to do a new SeaMonkey Profile to examine behavior with a CLEAN profile, not your old one. Mozilla app profiles can be corrupted, crufted with old bits of extensions/themes/plugins no longer used, etc. Please do it with a 100% clean default profile. If the issue doesn't occur there, it's something in your profile itself.
Bug closed 2012-08-22 after no response from reporter
Sometimes, the impossible can become possible, if you're awesome!