SeaMonkey 2.35b7

classic Classic list List threaded Threaded
55 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: SeaMonkey 2.35b7

Doug Bissett-2
On Sun, 7 Aug 2016 20:27:15 UTC, Dave Yeo <[hidden email]>
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)

_______________________________________________
dev-ports-os2 mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-ports-os2
Reply | Threaded
Open this post in threaded view
|

Re: SeaMonkey 2.35b7

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

_______________________________________________
dev-ports-os2 mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-ports-os2
Reply | Threaded
Open this post in threaded view
|

Re: SeaMonkey 2.35b7

Doug Bissett-2
On Mon, 8 Aug 2016 18:17:15 UTC, Steve Wendt <[hidden email]>
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.

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

_______________________________________________
dev-ports-os2 mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-ports-os2
Reply | Threaded
Open this post in threaded view
|

Re: SeaMonkey 2.35b7

Dave Yeo-3
Doug Bissett wrote:

> On Mon, 8 Aug 2016 18:17:15 UTC, Steve Wendt <[hidden email]>
> 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. I do and it gave me quite a bit more (low) shared 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.
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. 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.
It's irritating.
Dave
_______________________________________________
dev-ports-os2 mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-ports-os2
Reply | Threaded
Open this post in threaded view
|

Re: SeaMonkey 2.35b7

Doug Bissett-2
On Tue, 9 Aug 2016 03:13:36 UTC, Dave Yeo <[hidden email]>
wrote:

> Doug Bissett wrote:
> > On Mon, 8 Aug 2016 18:17:15 UTC, Steve Wendt <[hidden email]>
> > 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.

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

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

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

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

_______________________________________________
dev-ports-os2 mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-ports-os2
Reply | Threaded
Open this post in threaded view
|

Re: SeaMonkey 2.35b7

Dave Yeo-3
Doug Bissett wrote:

> On Tue, 9 Aug 2016 03:13:36 UTC, Dave Yeo <[hidden email]>
> wrote:
>
>> Doug Bissett wrote:
>>> On Mon, 8 Aug 2016 18:17:15 UTC, Steve Wendt <[hidden email]>
>>> 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

_______________________________________________
dev-ports-os2 mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-ports-os2
Reply | Threaded
Open this post in threaded view
|

Re: SeaMonkey 2.35b7

Dave Yeo-3
On 08/08/16 11:47 PM, Dave Yeo wrote:
> 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.

Also you should use bldlevel to verify that you haven't accidentally
loaded the wrong kernel as earlier kernels are known for crashing when
unloading DLLs loaded high
Dave
_______________________________________________
dev-ports-os2 mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-ports-os2
Reply | Threaded
Open this post in threaded view
|

Re: SeaMonkey 2.35b7

Doug Bissett-2
On Tue, 9 Aug 2016 07:04:17 UTC, Dave Yeo <[hidden email]>
wrote:

> On 08/08/16 11:47 PM, Dave Yeo wrote:
> > 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.
>
> Also you should use bldlevel to verify that you haven't accidentally
> loaded the wrong kernel as earlier kernels are known for crashing when
> unloading DLLs loaded high
> Dave

AFAICT it is the kernel from eCS 2.2b2, but I am not 100% sure that I
got all the parts that go with it. However, I do see the same problems
with eCS 2.2b2, when I boot to it.

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

_______________________________________________
dev-ports-os2 mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-ports-os2
Reply | Threaded
Open this post in threaded view
|

Re: SeaMonkey 2.35b7

Doug Bissett-2
In reply to this post by Dave Yeo-3
On Tue, 9 Aug 2016 06:47:26 UTC, Dave Yeo <[hidden email]>
wrote:

> Doug Bissett wrote:
> > On Tue, 9 Aug 2016 03:13:36 UTC, Dave Yeo <[hidden email]>
> > wrote:
> >
> >> Doug Bissett wrote:
> >>> On Mon, 8 Aug 2016 18:17:15 UTC, Steve Wendt <[hidden email]>
> >>> 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)

_______________________________________________
dev-ports-os2 mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-ports-os2
Reply | Threaded
Open this post in threaded view
|

Re: SeaMonkey 2.35b7

Andreas Schnellbacher-2
In reply to this post by Dave Yeo-3
Dave Yeo wrote:

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

Since I've discovered "System Load: DosQuerySysInfo()" as my needed
live monitor for shared and private memory, I'm experimenting a bit
more agian.

About EPM: I see often crashes in etke603.dll, with an entry in
popuplog.os2. Often, because I test a lot, also not very usual
situations. Since yesterday, I know that it always happens when the
lower shared mem is 0 MB.

I tried with highmem.exe to load the data of etke603.dll high. Then
EPM won't start anymore. But loading only its code high works well.
Not much won, but at least a new DLL that allows for loading to
higher shared memory. Since etke603.dll is responsible for the main
part, the edit control, loading its dat high should probably have
cured that problem.

Sinnce yesterday, I'm able to load a bit more than 60 MB files in EPM,
before that it was only 52. It doesn't matter how many files are loaded,
just the sum counts. Closing a file won't release that memory, at least
not until all EPM processes are closed. But I'm also experimenting with
VIRTUALADDRESSLIMIT at the same time.

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

We need a text eitor that is able to load large files partly. VSlick is
an example, MED and, IIRC, JEdit are not.

About Mozilla and strange shared memory behavior: I notice that
closing a recent Mozilla (I use SeaMonkey 2.35) won't release all lower
shared memory that was available before on close. It works only well
for the higher shared memory.

I've loaded several DLLs high, among them is /b xul.dll.

--
Andreas Schnellbacher
_______________________________________________
dev-ports-os2 mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-ports-os2
Reply | Threaded
Open this post in threaded view
|

Re: SeaMonkey 2.35b7

Andreas Schnellbacher-2
In reply to this post by Doug Bissett-2
Doug Bissett wrote:

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

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

A last OT comment on that: EPM knows both, line and stream mode.
See the NEPMD project on netlabs.org trac for easier configuration.

--
Andreas Schnellbacher
_______________________________________________
dev-ports-os2 mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-ports-os2
Reply | Threaded
Open this post in threaded view
|

Re: SeaMonkey 2.35b7

Peter Brown
In reply to this post by Dave Yeo-3
Hi All

Dave Yeo wrote:
> Uploaded
> https://bitbucket.org/dryeo/dry-comm-esr31/downloads/seamonkey-2.35b7.en-US.os2.zip
>
> Same requirements as FF38.8.0b7. Unluckily Lightning still broken. Drag
> & drop between address books fixed
> Dave



Just updated the Mrs system to use this browser.

That has put me in the doghouse as the browser fails to start displaying
"Couldn't load XPCOM." - must be the most unhelpful error message around
these days.

Having checked all required libs are present and on libpath what else do
I need to check?


Regards

Pete
_______________________________________________
dev-ports-os2 mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-ports-os2
Reply | Threaded
Open this post in threaded view
|

Re: SeaMonkey 2.35b7

Peter Brown
Hi All

Peter Brown wrote:

> Hi All
>
> Dave Yeo wrote:
>> Uploaded
>> https://bitbucket.org/dryeo/dry-comm-esr31/downloads/seamonkey-2.35b7.en-US.os2.zip
>>
>>
>> Same requirements as FF38.8.0b7. Unluckily Lightning still broken. Drag
>> & drop between address books fixed
>> Dave
>
>
>
> Just updated the Mrs system to use this browser.
>
> That has put me in the doghouse as the browser fails to start displaying
> "Couldn't load XPCOM." - must be the most unhelpful error message around
> these days.
>
> Having checked all required libs are present and on libpath what else do
> I need to check?
>


The answer was to recheck the libicu package and then update that to
56.1-1 and then install libicu-legacy for whatever apps were using the
older libicu files.

And they said yum/rpm would make life easier...


Regards

Pete

_______________________________________________
dev-ports-os2 mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-ports-os2
Reply | Threaded
Open this post in threaded view
|

Re: SeaMonkey 2.35b7

Steve Wendt
On 8/21/2017 5:16 PM, Peter Brown wrote:

> And they said yum/rpm would make life easier...

They didn't say it would be *your* life that would be easier.  :)
_______________________________________________
dev-ports-os2 mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-ports-os2
Reply | Threaded
Open this post in threaded view
|

Re: SeaMonkey 2.35b7

Peter Brown
Hi Steve

Steve Wendt wrote:
> On 8/21/2017 5:16 PM, Peter Brown wrote:
>
>> And they said yum/rpm would make life easier...
>
> They didn't say it would be *your* life that would be easier.  :)


There we have it in a nutshell  ;-)


Regards

Pete
_______________________________________________
dev-ports-os2 mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-ports-os2
123