[Ext] Session Manager 0.4 to 0.4.3

[axis]

ok. I just re-enabled and shut down and got the issue to happen again. I let the script run through 8 cycles of the unresponsive script warning or about 5 minutes and it never did finish. And I have no crashrecovery.dat on my system. I have a.js and a .xpt in the clean profile folder, but the issue is not happening with that profile.

I will, for the sake of information, add the contents of the extensions.crashrecovery.* and extensions.sessionmanager.* settings from the prefs.js file here and wait for further instructions to get more information from you.
Thanks for your continued help with this.
c

user_pref("extensions.crashrecovery.restore_prompt", false);
user_pref("extensions.crashrecovery.resume_session", true);
user_pref("extensions.sessionmanager._hibernating", true);
user_pref("extensions.sessionmanager._running", true);
user_pref("extensions.sessionmanager.resume_session", "backup.session");

[old zeniko]

Well, writing the crashrecovery.dat file shouldn't take that long, anyway. Interesting... Would you mind updating to the testing version linked from the first post and see whether the issue continues? And if it does, I'll have to ask you to install the other extensions on the clean profile, after all, I'm afraid. Thanks for your patience.

[axis]

Okey dokey. I installed each of my extensions on the new, clean profile and tried each one, one at a time (i.e., I installed one, closed FF, opened FF, made sure it was active, closed FF and watched to see if the issue started). It never did happen.
I tried also to get the same mix of GreaseMonkey scripts that I have on my normal profile for the sake of consistency, but I couldn't get to userscripts.org to get the three I have. It just wouldn't connect. It seems to be down.

So I am guessing it is something with the regular profile I have, right? Any other things you want me to try? Any settings I might have tweaked? I did change a setting in about:config in addition to letting scripts run longer to limit the FF memory leak issue. I can't remember the name of the setting but that should not be the issue as I changed that after this issue started.

So, what next? anything? Or is this just me somehow?

As always, thank you,
c
Not that it matters, the order in which I installed the extensions into the new, clean profile is:
Session Manager (not the development version)
Another Delicious Sidebar 1.0
Gmail Manager 0.4.3.6
Performancing 1.2,
Tabrowswer Preferences 1.2.8.9
Greasemonkey 0.6.4
Deepest Sender 0.7.6
Forecastfox 0.9.0.2
and del.icio.us 1.1

[anon42]

Hi,
I hope I am in the right place to report this or get some help fixing it.... if not, please let me know.

I have what i think is a bug in session manager (the most updated version). Everytime I close Firefox (1.5.0.4 and the one that came before yesterday's update which I assume was 1.5.0.3) I get an unresponsive script warning with the option to stop the script or continue waiting. To get FF to close totally, I have to say stop script.... this happens no matter what Web site I am on or how many tabs I have open when I close it down.

Interesting. I haven't visited this thread for some time but I guess it's lucky I did.

I also am getting bunches of "Unresponsive script" warnings. But I think they only started coming out recently, i.e., since FF 1.5.0.4, and only from one site, http://www.versiontracker.com/macosx/. This site refreshes itself every few minutes, and is overly complicated (IMO). I just assumed that the problem was some garbage VersionTracker was sending to FF and it was FF generating that warning. It never occurred to me, until now, that it could be due to, or caused, by one of the extensions.

Anyway it's pretty reproducible on my machine (but not 100%) by just leaving the VersionTracker page up and waiting. I haven't experimented yet taking out extensions like Session Manager out to see if the problem goes away.

[Peng]

anon42:

You get the "unresponsive script" warnings for any script that's taking too long, whether it be from an extension or website. I really doubt Session Manager is the source of your VersionTracker woes.

[anon42]

anon42:

You get the "unresponsive script" warnings for any script that's taking too long, whether it be from an extension or website. I really doubt Session Manager is the source of your VersionTracker woes.

Yes, I had suspected it might be a timing issue since VersionTracker is the only page where this seems to happen. Because of all the crap (including ads I suppress) they try to shove down the pipe, and because I still live in the dark ages using a 28-modem connection, it takes longer than any other page to complete. So I am not surprised something would get tired of waiting. Hell, I do too!

FWIW, is there any config value to increase the time limit setting?

[Peng]

FWIW, is there any config value to increase the time limit setting?

dom.max_script_run_time.

[Elder Young]

All of a sudden Session Manager just decided to cause crashes every time that I try to startup. I had a bunch of tabs saved in a session, but I don't remember the pages. Is there anyway for me to open up the session files and see what tabs I had open?

[tmetro]

I notice a substantial performance hit when using Session Manager (0.4.1.6+) with Firefox 1.5.0.3/1.5.0.4.

Some specifics: the machine in question is an old machine running Windows NT. Firefox, even without any extensions, will start to perform poorly once some internal threshold is reached (see my comments in Bug 233872). Typically when the memory footprint gets up into the 200 MB range (and this is not due to swapping memory to disk). Once this threshold has been reached, most page rendering operations will peg the CPU at 100% for 5 to 15 seconds. But prior to hitting that threshold, the browser is quite usable.

I had previously been using Session Saver, which had the effect of accelerating how quickly the threshold was reached. This might have been in part due to the extra memory occupied by restored sessions and their history, but the overhead of Session Saver itself (saving history data periodically, etc.) undoubtedly had some impact as well, though the browser was still usable.

After switching to Session Manager (I got sick of Session Saver crashing on restore and not being able to easily decode its session storage format in order to manually recover), the point at which the browser becomes unusable is substantially accelerated, and it seems to be happening with a smaller memory footprint (150 MB). I noticed, for example, that even immediately after a restart that typing in a text area form control would result in typed text appearing in bursts, with several second pauses between the bursts. Disabling Session Manager eliminates this behavior.

While FF may suffer from a performance bug specific to NT which is beyond the scope of Session Manager, it also seems that the overhead introduced by Session Manager might need to be examined. Has the code undergone a performance optimization pass? Has it been profiled? (Anything I can do to help?)

I've upgraded to 0.4.1.7+ and I'll report back if that improves the situation.

-Tom

[Peng]

I noticed, for example, that even immediately after a restart that typing in a text area form control would result in typed text appearing in bursts, with several second pauses between the bursts.

I've noticed that frequently. (It's happening right now while typing this post.) I otherwise don't have any problems with Session Manager's performance, though. I don't know how much slower it makes Firefox, but it's fast enough.

[old zeniko]

So I am guessing it is something with the regular profile I have, right? Any other things you want me to try? Any settings I might have tweaked?

Might be either something wrong with your regular profile, or rather just a pretty exotic incompatibility which is difficult to get hold on. I'm no longer sure that it's got something to do with the file parsing/writing, since I've just had a 0.5 MB crashrecovery.dat and didn't notice any performance hit at all. Of course, it might also be that your hardware is much more restricted than mine (although mine is already over 3 years old as well).

I also am getting bunches of "Unresponsive script" warnings.

I'm not able to reproduce the issue related to the Versiontracker page. If this issue continues and you manage to shut down Firefox after an "Unresponsive script" warning, please mail me your crashrecovery.dat. Otherwise please make sure that you get no warnings/errors in the JS console (having javascript.options.showInConsole set to true).

All of a sudden Session Manager just decided to cause crashes every time that I try to startup. I had a bunch of tabs saved in a session, but I don't remember the pages. Is there anyway for me to open up the session files and see what tabs I had open?

This particular crash introduced with the latest Bon Echo nightlies should be fixed as of today's <a href="http://www.haslo.ch/zeniko/software/sessionmanager-dev.xpi">testing version</a> (0.4.1.8+). The session files can be opened in any text editor (Notepad, vi, etc.) and should be easily human readable.

I noticed, for example, that even immediately after a restart that typing in a text area form control would result in typed text appearing in bursts, with several second pauses between the bursts.

I'm not sure I correctly understand you: does this mean that if you type at a regular speed, you'll just get what you typed every few seconds, but all at once? Or do you mean that when typing it lags every few seconds? If it is the latter, try increasing the time interval in the advanced Session Manager options up to 30 or 60.

Has the code undergone a performance optimization pass? Has it been profiled?

There have already been several optimization phases, but I've never profiled it completely (for which I lack the tools). Of course not being affected by any performance hits doesn't really help, either.

One thing you could try is to remove the following line from crashrecovery.js (located somewhere in your profile) and see whether the issue goes away:

Code: Select all

aBrowser.addEventListener("input", onTabInput_browser, true);

(resp. instead of removing it, just prepend it with a double-slash: //).

I've noticed that frequently.

Which part of it, that it blocks at certain intervals or that it always blocks?

[Peng]

Which part of it, that it blocks at certain intervals or that it always blocks?

Just that text input freezes every few seconds and then the text I've typed appears after in unfreezes, when it's backed up. Ignore me.

[tmetro]

...typed text appearing in bursts, with several second pauses between the bursts.

...does this mean that if you type at a regular speed, you'll just get what you typed every few seconds, but all at once? Or do you mean that when typing it lags every few seconds? If it is the latter, try increasing the time interval in the advanced Session Manager options up to 30 or 60.

At the moment it is lagging periodically, and that period seems like it probably matches the 10 second update period.

Once the "threshold" has been crossed in the browser, though, typing into a text area is so painfully slow that I end up typing in an editor and pasting in the text. If I remember correctly, it isn't just poor responsiveness, but the act of typing itself drives up the CPU usage, as if there was a JS handler monitoring keystrokes. (Which can be the case on some sites, but not the sites I typically use.)

Other examples of slowness that are observable before the threshold is reached include the initial rendering of the Session Manager menu (15 to 20 seconds) and displaying the options dialog (10 to 15 seconds). Is rendering the menu dependent on parsing the session files or something? At the moment I have about 20 sessions listed.

Examples post threshold: clicking on tabs can be sluggish. With Session Manager active, switching to another tab takes several seconds. (Does Session Manager hook into that event?)

I think ultimately the solution will require figuring out the root cause of the FF bug that causes it to switch into its CPU sapping behavior. Session Manager may be slightly worse than Session Saver in contributing to that problem, but it has fairly acceptable performance prior to hitting the threshold. Reducing Session Manager's memory requirements might have a beneficial effect on the situation.

I've never profiled it completely (for which I lack the tools).

The Venkman JavaScript Debugger includes a profiler. Having used the profiler only once, I can't say how good/useful it is.

One thing you could try is to remove the following line from crashrecovery.js...

What are the consequences of removing that event handler?

All of a sudden Session Manager just decided to cause crashes every time that I try to startup.

Perhaps related to this or the same thing, I've noticed on several occasions on startup that I'll be prompted by Session Manager to select a session, then a minute later I'll be prompted again, now with a newly added Crashed Session... option. Technically, it doesn't seem anything has crashed. Is Session Manager setting a time limit on page loads and assuming a crash if the time is exceeded? If so, I probably need to boost that threshold on this system.

-Tom

[anon42]

You get the "unresponsive script" warnings for any script that's taking too long, whether it be from an extension or website. I really doubt Session Manager is the source of your VersionTracker woes.

I also am getting bunches of "Unresponsive script" warnings.

I'm not able to reproduce the issue related to the Versiontracker page. If this issue continues and you manage to shut down Firefox after an "Unresponsive script" warning, please mail me your crashrecovery.dat. Otherwise please make sure that you get no warnings/errors in the JS console (having javascript.options.showInConsole set to true).

Peng's reply to my post appears to be the correct one (thanks Peng). In a followup reply when I asked if there was some FF config setting to change the wait time he said it was dom.max_script_run_time. I googled "dom.max_script_run_time" and sure enough I am not the only one getting "unresponsive script". So it really has nothing to do with Session Manager after. It's only, in my case, trying to access an overly complicated page with my slow modem connection. I've since increased the value of dom.max_script_run_time a little bit and I am not longer seeing the "unresponsive script" dialogs (thanks again for that too Peng).

[old zeniko]

At the moment it is lagging periodically, and that period seems like it probably matches the 10 second update period.

In that case, I recommend you once more to change that interval to something around 30 or even 60 seconds to alleviate the issue.

as if there was a JS handler monitoring keystrokes.

There is: Session Manager itself monitors your inputs.

Is rendering the menu dependent on parsing the session files or something?

Yes, Session Manager has to parse the session files in order to extract the sessions' names (it does however cache the names so that it doesn't have to read them more than once per window).

(Does Session Manager hook into that event?)

It does so as well, but the impact should be minimal.

Reducing Session Manager's memory requirements might have a beneficial effect on the situation.

I'm afraid, there's not much I can do here without some sacrifices. You might want to try to reduce the number of reopenable closed tabs to 3 (or even 0) to get more free memory and set the maximum amount of saved POSTDATA to 0 which might also help.

What are the consequences of removing that event handler?

Text you input will no longer be saved (that's the keystroke handler mentioned above).

I've noticed on several occasions on startup that I'll be prompted by Session Manager to select a session, then a minute later I'll be prompted again, now with a newly added Crashed Session... option. Technically, it doesn't seem anything has crashed. Is Session Manager setting a time limit on page loads and assuming a crash if the time is exceeded?

Are you saying that you get the recover session dialog twice when you start Firefox? Page load time doesn't have anything to do with perceived crashes - just incomplete shutdowns.