Re: SeaMonkey 2.35b7

On Tue, 9 Aug 2016 06:47:26 UTC, Dave Yeo <[email protected]> 
wrote:

> Doug Bissett wrote:
> > On Tue, 9 Aug 2016 03:13:36 UTC, Dave Yeo <[email protected]>
> > wrote:
> >
> >> Doug Bissett wrote:
> >>> On Mon, 8 Aug 2016 18:17:15 UTC, Steve Wendt <[email protected]>
> >>> wrote:
> >>>
> >>>> On 8/7/2016 6:38 PM, Doug Bissett wrote:
> >>>>
> >>>>>> 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.
> >>>>>
> >>>>> Well, you are a special case.
> >>>>
> >>>> Selective snipping to make a point - clearly you are doing something
> >>>> unusual at startup.  You've said it's not ClamAV, but it must be
> >>>> something that you are running.
> >>>
> >>> Some investigation reveals that CLAMD.EXE is using about 6 MB of low
> >>> shared memory. I assume that is from the "common" DLLs that it uses.
> >>> Running the AOO QuickStart thing uses an additional  3 MB. XCenter
> >>> seems to use about 20 MB. All of that accounts for the 29 MB that gets
> >>> used between the time Above512Watch gets started, until the sytstem is
> >>> ready to use. At that point it says I have about 241 MB available. If
> >>> I start FF (with, or without, RUN!), it drops to about 130 MB.
> >>>
> >>> I will need to dig into CONFIG.SYS to see what it starts up.
> >>>
> >>
> >> I can't remember if you have DLLBASING=OFF at the head of your
> >> config.sys.
> >
> > Yes, I do, but I think that is part of the problem. It causes
> > fragmentation of the shared memory, and that may prevent getting
> > enough contiguous memory for the programs. Unfortunately, not using it
> > is even worse.
> >
> >> I do and it gave me quite a bit more (low) shared memory.
> >
> > I am pretty sure that there is lots of free memory, but it isn't
> > contiguous after a few starts and stops, so those huge DLLs can't
> > load.
> 
> What do you have set for VIRTUALADDRESSLIMIT? I have 3072 (needed for 
> linking debug xul.dll) and need to test lowering it. There is a danger 
> of stepping on system (hardware) memory.

I am using 3072. This machine has 8 G in it. I use part of that with 
the QSINIT RAMDISK, but that is all above 4 G, except the driver. From
past experimenting, 1024 has one set of problems, 2048 has another set
of problems. 1536 has fewer problems, but I see problems from both 
1024 and 2048. 3072 has problems, but not as many as 1536.

> >
> >> Still, there are other problems. Today I fired up SM 2.5 (Gecko 8) to
> >> fix places not keeping history, this never was marked to load high and
> >> Free Shared Mem showed a 100MB drop right away, things ran smooth with
> >> about 150 MBs free, upon closing I saw the free memory briefly drop to
> >> 100 MBs before rebounding to about 250 MBs. I also took the opportunity
> >> to mark some of the requirements to load high, Fontconfig, Pango,
> >> Freetype, Cairo and Pixman for now.
> >
> > The main reason why I haven't tried some of them, is that I am worried
> > about other programs that might use them. If something tries to use
> > them, and it isn't designed to use high memory, there will be trouble.
> 
> I think as long as they're not calling the 16 API, they're fine.

How would a use know?
>
> > If it is designed to use high memory, it will likely crash on exit. I
> > have tried a few things (like the XCENTER plugins), but that doesn't
> > work.
> 
> Some of the plugins probably call the 16 API. I know the drives object does.

What I see is a blank screen when the XCenter(s) start up.

> >
> >> Going back to SM 2.35 things ran fine, history was back to working and
> >> starting SM only used a couple of MBs of low shared memory.
> >
> > I do notice that FF works very well, when loaded high. Even if it just
> > crashed at close, it would be almost worth the effort, but when it
> > takes out the whole system, about 80% of the time, it isn't worth it
> > any more. I don't like to let FF run over night, or when I am not
> > around. I do load AOO high, and run the Quick Start thing to keep the
> > DLLs from unloading. That seems to be good, but it also uses some
> > lower shared memory.
> >
> >> Later after
> >> having shutdown TB and SM, I fired up TB first and then clicked the SM
> >> icon (run!L), bang reboot, didn't even get far enough to break
> >> profiles.ini. This was with about 250MBs free lower shared memory.
> >
> > In a case like that, you really can't tell what happened, unless you
> > take a system dump, and know how to use it. Even then, I suspect that
> > all it would show would be a memory overlay.
> >
> >> It's irritating.
> >> Dave
> >
> > It needs to be fixed, somehow. What I find "irritating" is that I have
> > watched lower shared memory step down to 2 MB, before a program crash,
> > while I have almost 2000 MB of upper shared memory available.
> > Unloading upper shared memory seems to be where one of  the problems
> > lies, so it would make sense to try to keep those DLLs, that use it,
> > loaded all of the time (seems to work with AOO).
> 
> I've found that things get funky when lower shared memory gets below 10 
> MBs, though my monitoring program disagrees with others by about 10 MBs 
> so it is hard to say exactly. 

Mine gets funky when it drops below 90 meg (using Above512Watch). That
doesn't show exactly what Free Shared Mem shows, and SHMEMMON is quite
different.

> It was interesting when I accidentally 
> built SM without -Zhigh-mem so memory was getting allocated low. 
> Couldn't even finish loading my default profile.

That happens after starting and stopping FF a few times.

> Understand that we allocate memory high as well as hopefully load the 
> DLL code and data high. Have you tested just loading the code or data 
> high? 

I have been doing both.

> That's what I did (code IIRC) before getting the 106 kernel as the 
> 105 kernel did crash on exit here.

I am using the 106 kernel. Apparently part of the problem was fixed, 
but there are still problems. Somebody is working on it, but I have 
seen no results, yet.

> Hopefully the 200 kernel that Blue Lion uses will fix these issues.

They are trying. Whether it will fix it, or not, remains to be seen.

> >
> > Other things, like AE.EXE need to be investigated, to see if they can
> > be rewritten to use upper shared memory, or better yet, private
> > memory.
> 
> It probably allocates memory in the low arena. Unluckily I think it was 
> written in Pascal, which has no support for high memory. If written in C 
> or C++, it could be recompiled and linked with GCC or the latest 
> unreleased OW to allocate memory high.

I question why it uses shared memory at all, but that may be out of 
the programmer's control.

> > I have been looking to see if I can find a substitute program,
> > but haven't found one yet. JEdit looks okay, but takes far too long to
> > load. EPM doesn't seem to use much shared memory, but it will take a
> > bit of getting used to.
> >
> 
> I use EPM sometimes. It also has a habit of crashing occasionally, 
> perhaps due to memory problems. I like it but it is a line editor so 
> somewhat weird.

That is why I rarely use it (only to peek at locked log files, 
mostly). I should try TEdit.

> Seems there should be lots of editors floating around as it is a usual 
> practice program.

I haven't had time to look.

> Dave
 


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