Re: SeaMonkey 2.35b7

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.

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

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

>
>> 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. 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.
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? That's what I did (code IIRC) before getting the 106 kernel as the 
105 kernel did crash on exit here.
Hopefully the 200 kernel that Blue Lion uses will fix these issues.

>
> 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 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.
Seems there should be lots of editors floating around as it is a usual 
practice program.
Dave