Re: SeaMonkey 2.35b7

On Sun, 7 Aug 2016 20:27:15 UTC, Dave Yeo <[email protected]> 
wrote:

> Doug Bissett wrote:
> >> I've mentioned before that I think there's room for two means of
> >> >packaging and distribution here:
> >> >
> >> >a) yum install seamonkey thunderbird firefox
> >> >I believe this is the eventual goal of bitwise, but as everyone knows,
> >> >this simply does not work yet.
> >> >
> >> >b) static build with minimal external dependencies, like Mozilla
> >> >distributes, and we had previously.  Both ZIP and installer package
> >> >(WarpIn or otherwise) are perfectly viable.
> >> >
> >> >Doug has been making WarpIn packages for quite some time, which I
> >> >commend him for, but I feel they are currently pointless, since it
> >> >doesn't do anything about dependencies.  Isn't the point of an
> >> >installation package to set everything up for you?  I'm not faulting
> >> >Doug for that, just pointing out that option b above is what needs to be
> >> >packaged for it to be viable.
> > I think that a) will be an option, in the near future, and that will
> > make other methods obsolete. If you haven't looked seriously at
> > installing, and using Arca Noae Package Manager (ANPM), I suggest that
> > you do so. It makes life a whole lot easier. I don't agree with the
> > way the RPM/YUM does things, but that is the way that was chosen by
> > those who do it, so we are stuck with it, and it will become even more
> > important to follow that path in the future as more programs are
> > packaged that way. The whole thing is a LOT better than it was when
> > the ANPM project was started, and ANPM makes it easy to operate
> > RPM/YUM.
> >
> > On the other hand, option b) may become necessary just to overcome the
> > shared memory problems, but that doesn't mean that it can't be
> > distributed by RPM/YUM. After doing some investigation, we need to get
> > high shared memory working (it does work, as long as you never unload
> > the DLLs),
> 
> It does work here, at least until memory gets fragmented or some other 
> resource runs out. 

It may be that I always run out of some resource, and the monitors are
showing that it is lower shared memory space.

> Currently with TB and SM loaded, I have 256 MBs of 
> low shared memory available.

I start out with less than that, after booting (last boot it was 241 
MB). When I load FF, I am left with about 115 MB. After running for a 
while, it seems to stabilize at about 110 MB. If I close FF, then open
it again, I usually have about 92 MB left. Trying to start FF again is
hit and miss. Sometimes it goes, and doesn't use any more low shared 
memory (or very little). Sometimes it will start, and leave me with 
about 2 MB (any subsequent program will not start if it needs lower 
shared memory space). Sometimes it crashes, and sometimes it takes out
the whole system. I have no hope of getting a second Mozilla program 
to run unless I do it immediately after booting, but then many other 
things can't run.

> If I restart SM enough times, the system 
> will usually spontaneously reboot when loading SM or opening a new SM 
> window. Occasionally the system just freezes. This usually happens here 
> when Free Shared Memory app shows about 200MBs free.

I am usually okay until it drops below 100 MB, but that may depend on 
exactly what is running, and what order they got started.

> > or we need a way to keep, at least, XUL.DLL (perhaps
> > others) loaded all of the time (preferably high),  so it doesn't run
> > into a situation where it can't get enough contiguous memory to load.
> 
> Which XUL.DLL? Right now I loaded TB and then SM without RUN! or 
> LIBPATHSTRICT and Theseus shows both XUL.DLLs being loaded. Trying to 
> also run FF now gives a sqlite error about the version being too old, 
> which seems like a new error.

I don't care about getting a second one going, although that problem 
really needs to be fixed. I would be happy to just get FF to go. I do 
use RUN!, with no L. In fact, I have about 1900 MB of upper shared 
memory space free. All of the DLLs would fit in that, and that 
actually does work, until one of them gets closed, and then it is 
usually a system crash.

> The wildcard seems to be Calendar, or its DLL, calbscmp.dll. Without 
> Calendar installed, I was running all 3 Mozilla apps without 
> LIBPATHSTRICT. With it installed in only TB, I can load TB and then SM 
> but lately it fails if I have it installed in both SM and TB, with SM 
> crashing when loading the mail & news window. SM also seems to keep 
> reverting to an older version and even when the DLL is the same in both 
> apps, it crashes lately.
> Really it seems that it is just safer to use LIBPATHSTRICT or RUN!

But neither one actually fix the problem. Lower shared memory still 
runs out. I will note that the current tools (that I know about) for 
measuring shared memory usage are terribly inadequate, and only 
SHMEMMON shows that shared memory is returned to the pool when a 
program is closed. The problem seems to be that other programs can 
fragment the pool, and it seems that contiguous memory is required. 
Depending exactly how it all plays out, that memory can be available, 
or more often it is not.

> > It also needs to be fixed so that it just fails when it can't load the
> > DLLs. Now, it seems that it just keeps retrying, until the user
> > reboots (and a user won't know what is going on, if they don't have
> > Process Dumps enabled).
> 
> I haven't seen this. Here it seems to just reboot or freeze the system. 
> Occasionally I get a TRAP E in SM

I have only seen that one once (Above512Watch showed about 2 MB left).
As you note, most of the time either the system freezes, or I see a 
TRAP E (in FF in my case). I have also seen FF crash while not even 
using it.

> > I would also suggest that those who use only a
> > browser, should use FF. Those who use only e-mail, (and news etc.)
> > should use TB. Those who need both, should use SM.
> 
> Lots of people don't like FF, so prefer browsing with SM. I also run TB 
> for testing purposes.

Well, you are a special case. I will admit that I prefer FF over SM, 
and I don't use TB, except to see what it does with some oddball 
messages, but if I thought it would work better, I would use SM. 
Unfortunately, when it comes to shared memory usage, it seems to be 
worse than FF.
 
> > The idea is to have
> > only ONE XUL.DLL loaded. Apparently, if you can get the right one,
> > they can all share XUL.DLL, but that seems to be hit and miss, at the
> > moment. In fact, part of the answer may be to simply drop FF and TB,
> > and only update SM, but SM is not an "official" project, so that
> > causes other problems.
> 
> Then there are the people who don't like SM and prefer FF.
> 
> >
> > I will note, that I gave up trying to verify requirements, with
> > WarpIn, because Bitwise gave up trying to document that stuff (too
> > complicated), and simply said to use RPM/YUM (meaning ANPM to make it
> > easy). I did consider looking to see if the user has RPM/YUM
> > installed, and simply run the command to do the updates, if it was
> > found, but that didn't seem to be a good idea if the user had it
> > installed, but wasn't actually using it. As it turned out, those who
> > use ANPM spent about 2 minutes (depending on download speed) getting
> > the requirements installed, and those who don't use ANPM spent days
> > trying to figure it out. Steve made that much easier, but his package
> > still doesn't contain all of the parts that ANPM includes, and it will
> > be the same thing next time. Possibly worse.
> >
> > One thought (Dave, perhaps you can do something), is to have a program
> > that will simply load XUL.DLL, and keep it loaded in high shared
> > memory space when FF is closed. currently, it seems to take about 90
> > meg to load XUL.DLL, and it seems that that must be contiguous memory.
> 
> That should be possible. Mozilla used to pre-load the DLLs if you ran 
> their pre-loader program and Dink had a program that did similar.
> I'd assume that you just need a small program linked against XUL.DLL 
> that is left running. Not sure how it handles XUL data, does it get 
> unloaded when FF closes?

I don't know. I would presume that it does. Whether it needs to, or 
not, is part of the question. I also don't know how loading three 
XUL.DLLs into high memory could be accomplished.

> > If another program loads something after that, and it stays in memory
> > when FF is closed, and something else  uses another chunk of shared
> > memory, it can come out of the part that XUL.DLL was using. Now, when
> > XUL.DLL tries to load, it can't find enough contiguous shared memory
> > space to be able to load XUL.DLL. That just happened to me, and the
> > result was repeating Process Dumps, all pointing to Firefox (no *.TRP
> > files, or entries in POPUPLOG.OS2). That kept on repeating until I
> > rebooted. If XUL.DLL was loaded, and stayed in memory, that problem
> > wouldn't happen. Of course, FF should also detect that it couldn't
> > load the DLL, and inform the user of the problem.
> 
> I don't know why Mozilla hasn't added code to inform about not being 
> able to allocate enough continuous memory as it is also a major problem 
> on 32 bit Windows. Eventually it'll probably be only 64 bit to avoid 
> these issues.
> Dave

They are getting almost as bad as Microsoft. It would seem to me that 
it would be better to split XUL.DLL into many smaller parts, but what 
do I know? At least the contiguous memory requirement would be much 
less, and DLLBASING=OFF would be able to do what it is supposed to do.

-- 
From the eComStation of Doug Bissett
dougb007 at telus dot net
(Please make the obvious changes, to e-mail me)