Firefox 10.09ESR

Firefox 10.09esr has been uploaded to Netlabs.
This is another security fix update and all users of the 10 branch are 
urged to update
Dave
0
Dave
10/13/2012 2:32:26 AM
mozilla.dev.ports.os2 2337 articles. 0 followers. Post Follow

111 Replies
773 Views

Similar Articles

[PageSpeed] 52

Dave Yeo wrote:
> Firefox 10.09esr has been uploaded to Netlabs.
> This is another security fix update and all users of the 10 branch are
> urged to update
> Dave

SeaMonkey also uploaded.
Dave
0
Dave
10/13/2012 5:23:02 PM
On 10/13/12 10:23 am, Dave Yeo wrote:

> SeaMonkey also uploaded.

Thanks Dave!
0
Steve
10/13/2012 6:06:50 PM
On 10/13/12 01:23 pm, Dave Yeo wrote:
> Dave Yeo wrote:
>> Firefox 10.09esr has been uploaded to Netlabs.
>> This is another security fix update and all users of the 10 branch are
>> urged to update
>> Dave
>
> SeaMonkey also uploaded.

I just installed the new SM and was looking at the Release Notes - 
specifically the:
     "Security Advisories for SeaMonkey"
There are a number of issues listed as "Critical" and that have been 
fixed in a number of levels far higher than the 2.7.2 level for the SM 
that was just released.  Specifically, there are two critical items 
"Fixed in SeaMonkey 2.13.1"

Why are the OS/2 levels so far behind?  There are no dates on these 
levels so there is no way to put a time frame around these newer levels.
-- 
TIA
Carl
0
Carl
10/14/2012 1:20:56 AM
Carl Gehr wrote:
> On 10/13/12 01:23 pm, Dave Yeo wrote:
>> Dave Yeo wrote:
>>> Firefox 10.09esr has been uploaded to Netlabs.
>>> This is another security fix update and all users of the 10 branch are
>>> urged to update
>>> Dave
>>
>> SeaMonkey also uploaded.
>
> I just installed the new SM and was looking at the Release Notes -
> specifically the:
> "Security Advisories for SeaMonkey"
> There are a number of issues listed as "Critical" and that have been
> fixed in a number of levels far higher than the 2.7.2 level for the SM
> that was just released. Specifically, there are two critical items
> "Fixed in SeaMonkey 2.13.1"
>
> Why are the OS/2 levels so far behind? There are no dates on these
> levels so there is no way to put a time frame around these newer levels.

Strictly speaking, this should be called 2.7.9 as it is built upon 
Mozilla 10.0.9, the extended support tree. As SeaMonkey doesn't 
officially support the ESR branch I've left the default of 2.7.2. 
Security fixes are here, 
https://www.mozilla.org/security/known-vulnerabilities/firefoxESR.html. 
Thunderbird has also had a couple of mail related security updates which 
also apply to SeaMonkey.
The OS/2 builds are so far behind due to lack of developers. I can build 
newer versions but they crash if there are any add-ons, often breaking 
the profile as well. I'm no good at debugging the complicated JavaScript 
code and have spent close to a year trying to trace where things broke. 
Unluckily this has not been simple as the development tree branches of 
frequently then merges back in and I'm not always motivated so I'll 
spend some weeks testing revisions which is tedious, then spend some 
weeks not doing anything related to Mozilla.
I'm doing this volunteerly as I also like an up to date browser and it 
can be interesting but the rapid release schedule really calls for full 
time developer(s).
Dave
0
Dave
10/14/2012 1:49:37 AM
Steve Wendt wrote:
> On 10/13/12 10:23 am, Dave Yeo wrote:
>
>> SeaMonkey also uploaded.
>
> Thanks Dave!

I should note that I skipped the 10.0.8 release as only 5 days passed 
between the 0.8 and 0.9 releases
Dave
0
Dave
10/14/2012 1:51:43 AM
Hi Dave!


On Sat, 13 Oct 2012 02:32:26 UTC, Dave Yeo <dave.r.yeo@gmail.com> wrote:

> Firefox 10.09esr has been uploaded to Netlabs.
> This is another security fix update and all users of the 10 branch are 
> urged to update
> Dave


Just deployed it a couple of hours ago...very little runtime so far, but appears
to be running fine.

Thanks again!

-Dariusz
0
Dariusz
10/14/2012 1:55:43 AM
On Sun, 14 Oct 2012 01:49:37 UTC, Dave Yeo <dave.r.yeo@gmail.com> 
wrote:

> I'm doing this volunteerly as I also like an up to date browser and it 
> can be interesting but the rapid release schedule really calls for full 
> time developer(s).
> Dave

Without volunteers, eCS is toast. Unfortunately, we just don't have 
enough developers, full time or otherwise, but you are doing a 
reasonably good job of sorting out the basics. Thanks, for everything 
that you do.

Personally, I see no good reason for the rapid releases, other than to
add security fixes (and to try to look like they are keeping up with 
Internet Explorer, which is a silly thing to do). I think the ESR path
makes a lot more sense, but, eventually, we will need to jump to 
something newer. Hopefully, you can get some help.

I do, however, question the advisability of maintaining programs that 
effectively duplicate each other. Firefox, and Thunderbird, do what 
SeaMonkey does, and they are more "officially" supported. I know that 
there are many users who seem to prefer SeaMonkey, but if it is taking
significant time away from the other two, it may be wise to drop it. 
Some will say that it is Firefox, and Thunderbird, that should be 
dropped, but there is much less "official" support for SeaMonkey, so 
it would make sense to drop that. On the other hand, if SeaMonkey is 
not taking a significant amount of time, I have no problem if you wish
to continue the project. I just throw this thought out as a way to cut
down on the amount of work to be done.

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

0
Doug
10/14/2012 5:31:19 AM
On 2012-10-14 00:31 (GMT-0500) Doug Bissett composed:

> I do, however, question the advisability of maintaining programs that
> effectively duplicate each other. Firefox, and Thunderbird, do what
> SeaMonkey does,

Twice. They don't share what SeaMonkey need not share, so unless you only 
require web or email but not both, you're wasting precious low memory by 
redundant loading.

I just moved off eCS for web apps last month, and on Linux run 2 SeaMonkeys 
and 3 Firefoxes 24/7 with no crashing, no RAM shortage, and no 100% CPU 
periods. On eCS before I switched, SM needed daily restarts to reclaim lost 
shared RAM even without using it for news or CZ.

Now using SM on eCS only for CZ I'm lucky if I get 3 days out of it before it 
dies. Leaving SM open much more than a day using it only for web and CZ it 
crashes even with only 1/3 the number of open tabs I usually use.

Currently FC/2 is showing 2,145,906,688 total RAM, 1,666,961,408 free with 
only CZ, 2 DOS apps and FC/2 running. Closing the CZ window brought free RAM 
up to 2,033,229,824, meaning CZ was using 366,268,416 all by itself. 
Reopening SM browser only with the same 12 tabs open when last closed brought 
free RAM down by 192,917,504. Opening CZ with my default set of 15 tabs 
brought free RAM down by 23,822,336, but after closing browser free RAM only 
went back up to 1,827,016,704, meaning freshly opened CZ is nevertheless 
using 206,213,120. Imagine how much would be used by opening TB plus FF with 
the same 30-40 tabs I typically have open in SM on eCS plus the 100+ tabs I 
have open in Linux, or that plus CZ? I'd be out of shared RAM right out of 
the gate, if I even got out of the gate.

FF + TB = no thanks.
-- 
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

  Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/
0
Felix
10/14/2012 10:01:00 AM
Hi Dave!


On Sun, 14 Oct 2012 01:49:37 UTC, Dave Yeo <dave.r.yeo@gmail.com> wrote:

> > Why are the OS/2 levels so far behind? There are no dates on these
> > levels so there is no way to put a time frame around these newer levels.
> 
> The OS/2 builds are so far behind due to lack of developers. I can build 
> newer versions but they crash...
> Dave


So how the heck do the rest of us get involved? I had previously asked this 
question, received some pointers...spent some time looking into the project and 
quite frankly, was completely lost!!!

The code complexity is one thing, but the overall OS/2 framework, what resources
such as compiler, libraries, tools to use is nothing but a major brick wall. Is 
there not a document somewhere which spells out, one by one, how a given OS/2 
machine needs to be set up? Is there not a downloadable environment that could 
be utilized which is already pre-configured?

In my case, I have my daily use machine (which is SMP configured and is very 
fast for just about everything I ask it to do). I also have my old hardware 
still kicking around with a complete OS/2 environment setup that could be used 
as a spare box to do work with. Effectively, that means as a developer (I'm an 
IS professional by trade and spent a few years wearing exactly those shoes) I 
have my build & test boxes readily available to me. 

Given the rather steep climb on the Firefox project I have now started looking 
at the QT framework in hopes of compiling the new version of PSI IM client. Will
it work? ....no idea...but you've got to try to know.

I would much rather devote my time to something like Firefox, but again, much 
help is needed to get started...
0
Dariusz
10/14/2012 1:57:24 PM
On 10/13/12 10:31 pm, Doug Bissett wrote:

> Personally, I see no good reason for the rapid releases, other than to
> add security fixes (and to try to look like they are keeping up with
> Internet Explorer

I suppose you mean Chrome.  IE is always way behind.

> Some will say that it is Firefox, and Thunderbird, that should be
> dropped, but there is much less "official" support for SeaMonkey

Thunderbird has been "dropped" multiple times by Mozilla.
0
Steve
10/14/2012 5:28:48 PM
On 10/14/12 06:57 am, Dariusz Piatkowski wrote:

> The code complexity is one thing, but the overall OS/2 framework, what resources
> such as compiler, libraries, tools to use is nothing but a major brick wall. Is
> there not a document somewhere which spells out, one by one, how a given OS/2
> machine needs to be set up?

Apologies if you have already seen this; I don't know how out of date it is:
http://developer.mozilla.org/en/docs/OS/2_Build_Prerequisites
0
Steve
10/14/2012 5:31:15 PM
Doug Bissett wrote:
[...]
>
> Personally, I see no good reason for the rapid releases, other than to
> add security fixes (and to try to look like they are keeping up with
> Internet Explorer, which is a silly thing to do). I think the ESR path
> makes a lot more sense, but, eventually, we will need to jump to
> something newer. Hopefully, you can get some help.

It's Chrome that they're competing with. Unluckily they're also adding 
features that we're missing out on, It won't be too bad if we can jump 
to 17ESR by next year but if not then we'll fall further behind with a 
browser that doesn't support things like the new audio codec, new spdy 
http protocol and various HTML 5 features that have been added lately. 
As well at some point things like Google will refuse to work.

>
> I do, however, question the advisability of maintaining programs that
> effectively duplicate each other. Firefox, and Thunderbird, do what
> SeaMonkey does, and they are more "officially" supported. I know that
> there are many users who seem to prefer SeaMonkey, but if it is taking
> significant time away from the other two, it may be wise to drop it.
> Some will say that it is Firefox, and Thunderbird, that should be
> dropped, but there is much less "official" support for SeaMonkey, so
> it would make sense to drop that. On the other hand, if SeaMonkey is
> not taking a significant amount of time, I have no problem if you wish
> to continue the project. I just throw this thought out as a way to cut
> down on the amount of work to be done.
>

Once Firefox is building, it is trivial to build SeaMonkey and 
Thunderbird as they're basically built on top of Firefox.
As I use SeaMonkey and Thunderbird much more then Firefox I'll keep 
building them.
Dave
0
Dave
10/14/2012 5:57:38 PM
On Sun, 14 Oct 2012 10:01:00 UTC, Felix Miata 
<UgaddaBkidding.due2UCE@dev.nul> wrote:

> On 2012-10-14 00:31 (GMT-0500) Doug Bissett composed:
> 
> > I do, however, question the advisability of maintaining programs that
> > effectively duplicate each other. Firefox, and Thunderbird, do what
> > SeaMonkey does,
> 
> Twice. They don't share what SeaMonkey need not share, so unless you only 
> require web or email but not both, you're wasting precious low memory by 
> redundant loading.

I don't want to argue, but i would like to ask a couple of questions, 
make a few comments, and point out some numbers that I see <below>.

> I just moved off eCS for web apps last month, and on Linux run 2 SeaMonkeys 
> and 3 Firefoxes 24/7 with no crashing, no RAM shortage, and no 100% CPU 
> periods. On eCS before I switched, SM needed daily restarts to reclaim lost 
> shared RAM even without using it for news or CZ.

What makes you think that it is SM (or FF or TB) that is causing the 
problem? I will agree that they probably trigger a problem, but I have
seen similar problems without using FF (which is what I use, most of 
the time - I use PMMail for e-mail, and ProNews/2 for news groups). 
FWIW, I have never seen the 100% CPU problem. I also don't seem to be 
running out of RAM (shared or otherwise), but that is possibly because
of the way I set up, and use, my machine. I do see problems after a 
couple of days, whether FF runs, or not. I do need to use the machine 
for other things, to see problems. It will run, unused, for many days.

> Now using SM on eCS only for CZ I'm lucky if I get 3 days out of it before it 
> dies. Leaving SM open much more than a day using it only for web and CZ it 
> crashes even with only 1/3 the number of open tabs I usually use.
> 
> Currently FC/2 is showing 2,145,906,688 total RAM, 1,666,961,408 free with 
> only CZ, 2 DOS apps and FC/2 running. Closing the CZ window brought free RAM 
> up to 2,033,229,824, meaning CZ was using 366,268,416 all by itself. 
> Reopening SM browser only with the same 12 tabs open when last closed brought 
> free RAM down by 192,917,504. Opening CZ with my default set of 15 tabs 
> brought free RAM down by 23,822,336, but after closing browser free RAM only 
> went back up to 1,827,016,704, meaning freshly opened CZ is nevertheless 
> using 206,213,120. Imagine how much would be used by opening TB plus FF with 
> the same 30-40 tabs I typically have open in SM on eCS plus the 100+ tabs I 
> have open in Linux, or that plus CZ? I'd be out of shared RAM right out of 
> the gate, if I even got out of the gate.

I would like to post some numbers, as produced by the Above512 
program:

Shortly after boot:
current free virtual address space in kB (private / shared):
  365824 / 284480 below 512MB line, 917504 / 816652 above 512MB line

After starting Firefox (10.0.9), with a simple home page:
current free virtual address space in kB (private / shared):
  340288 / 254656 below 512MB line, 917504 / 816588 above 512MB line

After opening 4 tabs, with the most complicated web pages that I 
normally use, and opening ProNews/2, I see:
current free virtual address space in kB (private / shared):
  333952 / 246016 below 512MB line, 917504 / 816588 above 512MB line

Throw in TB, and I see:
current free virtual address space in kB (private / shared):
  304448 / 213696 below 512MB line, 917504 / 814856 above 512MB line

To me, this does not seem to be excessive memory use, and there is 
certainly no shortage of shared memory available (real memory is 
irrelevant because the swap mechanism will make up for that, until it 
runs out of disk space). It is not possible to separate usage by 
program, using Above512, but Theseus seems to show little memory 
leakage for FF, over the short term (a couple of hours). FF does use 
large amounts of memory (only a problem on a small real memory setup),
and running it does cause web pages to be cached in memory (as well as
on disk), which may appear to be memory leakage, but it isn't really a
leakage, it is simply using more memory. On my 2 GB system, I never 
see it go much over 850 MB used (unless I open a virtual machine), 
even after leaving FF open all day long (without using it heavily, 
because I don't use it that much). Closing FF does leave some DLLs 
loaded, which may also appear to be a leakage, but it is not.

I should also point out that I use Rich Walsh's RUN! to start FF and 
TB. I also close FF (and almost everything else) over night, so it 
doesn't interfere with my nightly backup (RSync to a USB disk drive).

I saw sombody (perhaps Rich Walsh) post that FF, TB, and probably SM, 
no longer use large amounts of shared memory space, so I am wondering 
if you are blaming your trouble on a problem that no longer exists, 
when the real problem is something else (possibly in SM, but more 
likey in a part of OS/2 itself). If somebody can identfy the actual 
cause of the problem, it can probably be fixed (likely a work around 
of some sort).

This also begs the question: Why would you use more than 4 or 5 open 
tabs? It must take longer to find an open tab, than to open a new one,
and close it when you are finished with it (just trying to understand 
the logic of opening 50, or more, tabs, never mind having multiple SM,
and FF, programs open).

> FF + TB = no thanks.

Actually, I agree. I use FF, PMMail, and ProNews/2. I have tried SM, 
and there is something about it that just doesn't seem right, to me 
(personal preference). I do use TB, every once in a while (perhaps 
once per month), just to compare to what PMMail does with an 
individual message, otherwise, I probably wouldn't even bother 
installing it.

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

0
Doug
10/14/2012 5:58:20 PM
Felix Miata wrote:
> I just moved off eCS for web apps last month, and on Linux run 2
> SeaMonkeys and 3 Firefoxes 24/7 with no crashing, no RAM shortage, and
> no 100% CPU periods. On eCS before I switched, SM needed daily restarts
> to reclaim lost shared RAM even without using it for news or CZ.
>
> Now using SM on eCS only for CZ I'm lucky if I get 3 days out of it
> before it dies. Leaving SM open much more than a day using it only for
> web and CZ it crashes even with only 1/3 the number of open tabs I
> usually use.

I haven't had problems with shared memory for a long time, I don't 
really use CZ but sometimes I do have a hundred tabs open spread over a 
couple of Windows as well as using Thunderbird for mail and often having 
Firefox also open with perhaps a dozen tabs. What I do run into is 
excess swapping as I only have 1 GB of memory. SeaMonkey will run for 
days without needing shut down though I do shut it down about once a day 
to back up everything as after about a week (less with eCS) the system 
will hang forcing a reboot and due to bandwidth limits it is faster to 
restore a backup and use session restore then to redownload a hundred tabs.
There is a bug somewhere that causes 100% CPU if I subscribe to too many 
newsgroups but as long as I don't I just about never hit 100% CPU usage 
on Warp V4. eCS seems worse for CPU.
Currently with about 70 tabs over 2 windows, mailnews open and a minimal 
CZ window open and also Thunderbird also open I have 48 MBs of free ram 
+ 80 MBs of swap usage.
Dave

0
Dave
10/14/2012 6:16:07 PM
Steve Wendt wrote:
> On 10/14/12 06:57 am, Dariusz Piatkowski wrote:
>
>> The code complexity is one thing, but the overall OS/2 framework, what
>> resources
>> such as compiler, libraries, tools to use is nothing but a major brick
>> wall. Is
>> there not a document somewhere which spells out, one by one, how a
>> given OS/2
>> machine needs to be set up?
>
> Apologies if you have already seen this; I don't know how out of date it
> is:
> http://developer.mozilla.org/en/docs/OS/2_Build_Prerequisites

This is close to accurate. Python needs to be newer and also include 
Mercurial. GCC also needs to be recent. Ksh instead of Ash and only some 
versions of Make correctly support the right features.
Dave
0
Dave
10/14/2012 6:21:26 PM
Dave Yeo escribi�:
> Steve Wendt wrote:
....
>> Apologies if you have already seen this; I don't know how out of date it
>> is:
>> http://developer.mozilla.org/en/docs/OS/2_Build_Prerequisites
>
> This is close to accurate. Python needs to be newer and also include
> Mercurial. GCC also needs to be recent. Ksh instead of Ash and only some
> versions of Make correctly support the right features.
> Dave

Perhaps it would be wise to update that page (or whatever others!) with 
accurate and up-to-date information. That way anyone who would eventually want 
to join in would have an easier time. If I ever get to try, I certainly won't 
aim to compile anything older than this 10.0.9esr.

Best regards,
0
ISO
10/14/2012 7:41:40 PM
On Sun, 14 Oct 2012 18:21:26 UTC, Dave Yeo <dave.r.yeo@gmail.com> wrote:

> Steve Wendt wrote:
> > On 10/14/12 06:57 am, Dariusz Piatkowski wrote:
> >
> >> The code complexity is one thing, but the overall OS/2 framework, what
> >> resources
> >> such as compiler, libraries, tools to use is nothing but a major brick
> >> wall. Is
> >> there not a document somewhere which spells out, one by one, how a
> >> given OS/2
> >> machine needs to be set up?
> >
> > Apologies if you have already seen this; I don't know how out of date it
> > is:
> > http://developer.mozilla.org/en/docs/OS/2_Build_Prerequisites
> 
> This is close to accurate. Python needs to be newer and also include 
> Mercurial. GCC also needs to be recent. Ksh instead of Ash and only some 
> versions of Make correctly support the right features.
> Dave


Yes, the page Steve posted was the original information I had looked at. Now 
given the input you provided Dave what can be done to allow additional folks 
like myself to come in an contribute?

I want to get up to speed quickly and require as little as possible of the 
constant hand-holding. Some help will obviously be needed to start off with 
(such as this discussion), but the sooner a new developer gets up to speed, the 
better.

Sooo....is there anyone in the OS/2 Firefox team (who is the team btw?, is there
a Netlabs like project site?) that could take on the process to re-fresh the 
'involvement roadmap'? I would be happy/thrilled to work with this person as the
lab rat! ;-)


0
Dariusz
10/14/2012 7:57:29 PM
Dariusz Piatkowski escribi�:
> On Sun, 14 Oct 2012 18:21:26 UTC, Dave Yeo<dave.r.yeo@gmail.com>  wrote:
>
>> Steve Wendt wrote:
>>> On 10/14/12 06:57 am, Dariusz Piatkowski wrote:
....
> Sooo....is there anyone in the OS/2 Firefox team (who is the team btw?, is there
> a Netlabs like project site?) that could take on the process to re-fresh the
> 'involvement roadmap'? I would be happy/thrilled to work with this person as the
> lab rat! ;-)

I can't do application code now, but I'm willing to test anything, from new 
builds to packaging to build environments. If that's of any use for you, 
contact me.

Best regards,
0
ISO
10/14/2012 8:41:22 PM
Dariusz Piatkowski wrote:
> On Sun, 14 Oct 2012 18:21:26 UTC, Dave Yeo<dave.r.yeo@gmail.com>  wrote:
>
>> Steve Wendt wrote:
>>> On 10/14/12 06:57 am, Dariusz Piatkowski wrote:
>>>
>>>> The code complexity is one thing, but the overall OS/2 framework, what
>>>> resources
>>>> such as compiler, libraries, tools to use is nothing but a major brick
>>>> wall. Is
>>>> there not a document somewhere which spells out, one by one, how a
>>>> given OS/2
>>>> machine needs to be set up?
>>>
>>> Apologies if you have already seen this; I don't know how out of date it
>>> is:
>>> http://developer.mozilla.org/en/docs/OS/2_Build_Prerequisites
>>
>> This is close to accurate. Python needs to be newer and also include
>> Mercurial. GCC also needs to be recent. Ksh instead of Ash and only some
>> versions of Make correctly support the right features.
>> Dave
>
>
> Yes, the page Steve posted was the original information I had looked at. Now
> given the input you provided Dave what can be done to allow additional folks
> like myself to come in an contribute?

We've fallen far behind and probably need a couple of months of 
developer time to get caught up.

>
> I want to get up to speed quickly and require as little as possible of the
> constant hand-holding. Some help will obviously be needed to start off with
> (such as this discussion), but the sooner a new developer gets up to speed, the
> better.

I'll try to get together a howto on building 10esr which is a good 
start. One problem is I've lost track of exactly which versions of the 
tools I'm using. Python for example, I use one of Pauls builds for 
compiling but IIRC not the newest. For Mercurial I use the Python 
installed by RPM, but once again the newest doesn't work.
I only took up building Mozilla to have the latest with no plans to get 
heavily involved in development, just pointing out build breaks and such 
to the more knowledgeable people. Eventually I became one of the few 
people who could build so I started uploading my builds. Unluckily I 
never kept notes about my environment which has evolved quite a bit over 
the years.
Before libc065 was released things were also getting quite hairy as many 
of the libc tools needed patching which complicated things.
We're right at the edge of what our ancient system is capable of

>
> Sooo....is there anyone in the OS/2 Firefox team (who is the team btw?, is there
> a Netlabs like project site?) that could take on the process to re-fresh the
> 'involvement roadmap'? I would be happy/thrilled to work with this person as the
> lab rat! ;-)
>
>

Currently I'm all there is in the way of a Firefox team. No project site 
or anything else currently
Dave
0
Dave
10/14/2012 8:58:25 PM
Alfredo Fern�ndez D�az wrote:
> Dave Yeo escribi�:
>> Steve Wendt wrote:
> ...
>>> Apologies if you have already seen this; I don't know how out of date it
>>> is:
>>> http://developer.mozilla.org/en/docs/OS/2_Build_Prerequisites
>>
>> This is close to accurate. Python needs to be newer and also include
>> Mercurial. GCC also needs to be recent. Ksh instead of Ash and only some
>> versions of Make correctly support the right features.
>> Dave
>
> Perhaps it would be wise to update that page (or whatever others!) with
> accurate and up-to-date information. That way anyone who would
> eventually want to join in would have an easier time. If I ever get to
> try, I certainly won't aim to compile anything older than this 10.0.9esr.
>

I was hoping to get around to trying to setup a RPM/YUM environment to 
simplify things but never got around to it. Before libc065 things also 
were getting complicated as many tools needed updating, things like emxomf.
Unluckily I haven't really kept notes on what versions of various tools 
I'm currently using and being bandwidth challenged it is hard to test.
I'll try to find time to write a howto and update the build requirements 
pages but to be honest, motivation comes and goes.
Dave

0
Dave
10/14/2012 9:03:30 PM
First of all, a million thanks for providing reasonably up-to-date builds, Dave!

Dave Yeo escribi�:
....
> Strictly speaking, this should be called 2.7.9 as it is built upon Mozilla
> 10.0.9, the extended support tree. As SeaMonkey doesn't officially support the
> ESR branch I've left the default of 2.7.2. Security fixes are here,
> https://www.mozilla.org/security/known-vulnerabilities/firefoxESR.html.

Maybe it would be better to keep in synch with SM numbering in the future. The 
ESR name tail should be a hint anyway, and that would prevent issues with 
overly sensitive addons (language packs come to mind).

[...]
> I'm doing this volunteerly as I also like an up to date browser and it can be
> interesting but the rapid release schedule really calls for full time
> developer(s).

Certainly. As you said in another branch of the thread below, I'm planning to 
take up building Mozilla with no plans to get heavily involved in development, 
just pointing out build breaks and such to the more knowledgeable people, etc. 
but I'm afraid this won't keep the boat floating much longer...
0
ISO
10/14/2012 9:10:36 PM
On Sun, 14 Oct 2012 20:58:25 UTC, Dave Yeo <dave.r.yeo@gmail.com> wrote:

> Dariusz Piatkowski wrote:
> > Yes, the page Steve posted was the original information I had looked at. Now
> > given the input you provided Dave what can be done to allow additional folks
> > like myself to come in an contribute?
> 
> We've fallen far behind and probably need a couple of months of 
> developer time to get caught up.


Point out what I/we (others interested in this, Al F. comes to mind as he's 
responding to the thread) can help out with...even the simplest of things...


> > Sooo....is there anyone in the OS/2 Firefox team (who is the team btw?, is there
> > a Netlabs like project site?) that could take on the process to re-fresh the
> > 'involvement roadmap'? I would be happy/thrilled to work with this person as the
> > lab rat! ;-)
> 
> Currently I'm all there is in the way of a Firefox team. No project site 
> or anything else currently
> Dave


OK, so would it be possible to move the project to something like Netlabs? I 
only suggest that b/c there seems to be a 'nice' interface to it. I know nothing
about Netlabs beyond this, I know nothing about any of the internal politics 
(are there any???), etc, etc... My hope is that a central OS/2 repository will 
make it easier for others to join the project.

Either way, given all the work you are doing...you need help. So if we can split
up the task into multiple ones (yeah, I understand not all the tasks can be 
divided up like that) hopefully the final goal of keeping Firefox in sync can 
get easier.

In general, what is the best starting place for the developer willing to take a 
crack at the Firefox application? I'm assuming there is a lot of non-platform 
specific stuff out there to digest first before really getting into out platform
specific details.

0
Dariusz
10/14/2012 10:43:35 PM
On 2012-10-14 12:58 (GMT-0500) Doug Bissett composed:

> What makes you think that it is SM (or FF or TB) that is causing the
> problem?

Other than PMView, which is only ever open while I'm actually using it, the 
only "native" apps (I don't count FC/2 as a "native" app, while XFile is 
tiny, inactive most of the time, and as prerequisite to critical WPS 
functionality, I don't count it either) I've opened on eCS in the last half 
decade are the Geckos. eCS is my all-important DOS, and until last month, it 
was my primary/preferred access to the web.

After boot and opening the essentials (FC/2 & XFile via startup folder, 2 DOS 
apps manually), FC/2 says I have 2,074,263,552 of 2,145,906,688 free. Once a 
Gecko (normally SM 2.x, as I typically go weeks or even months without 
opening any FF on eCS) have dropped free below 1,500,000,000, I can expect a 
it/them to die in short order.

SM 1.1.x would crash in the same free RAM area, but could go up to 8 days up 
before dropping free RAM below the critical 1,500,000,000 level and dying. I 
got in the habit of restarting at 6 day intervals to avoid history data loss 
from crashing. Session restore allows me to much more conveniently restart 
SM2 daily to avoid most crashes.

I've not seen the 20,971,520 byte swap grown post-boot in several years, and 
have no idea whether it's been used at all. Its time stamp only changes at 
boot time.

> This also begs the question: Why would you use more than 4 or 5 open
> tabs? It must take longer to find an open tab, than to open a new one,
> and close it when you are finished with it (just trying to understand
> the logic of opening 50, or more, tabs, never mind having multiple SM,
> and FF, programs open).

It's easier to find what I want time and time and time again in open tabs 
than it is in bookmarks or history. Each window has its own group of tab 
content types, rather like using pager or virtual desktops, keeping most easy 
enough to locate. Plus, in a tab, there's no waiting unless I restart or care 
for a reload, which frequently is exactly what I don't want to happen. Only 
one profile/Gecko installation is allowed access to Flash content, minimizing 
the possibility of crashes due to that abominable usability impediment.

> I use FF, PMMail, and ProNews/2

I use SM because:

1-it offers the same advantages of an integrated web suite that Netscape did
2-it's cross-platform, enabling me to support it for users of operating 
systems installed on their puters when they bought them, which in turn
3-reduces slightly the number of people polluting the web via Outhouse and 
Outbreak Excess

Once upon a time I used ProNews/2, but only because of 
https://bugzilla.mozilla.org/show_bug.cgi?id=60981
-- 
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

  Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/
0
Felix
10/15/2012 12:07:11 AM
Dariusz Piatkowski wrote:
> On Sun, 14 Oct 2012 20:58:25 UTC, Dave Yeo<dave.r.yeo@gmail.com>  wrote:
>
>> Dariusz Piatkowski wrote:
>>> Yes, the page Steve posted was the original information I had looked at. Now
>>> given the input you provided Dave what can be done to allow additional folks
>>> like myself to come in an contribute?
>>
>> We've fallen far behind and probably need a couple of months of
>> developer time to get caught up.
>
>
> Point out what I/we (others interested in this, Al F. comes to mind as he's
> responding to the thread) can help out with...even the simplest of things...
>
>
>>> Sooo....is there anyone in the OS/2 Firefox team (who is the team btw?, is there
>>> a Netlabs like project site?) that could take on the process to re-fresh the
>>> 'involvement roadmap'? I would be happy/thrilled to work with this person as the
>>> lab rat! ;-)
>>
>> Currently I'm all there is in the way of a Firefox team. No project site
>> or anything else currently
>> Dave
>
>
> OK, so would it be possible to move the project to something like Netlabs? I
> only suggest that b/c there seems to be a 'nice' interface to it. I know nothing
> about Netlabs beyond this, I know nothing about any of the internal politics
> (are there any???), etc, etc... My hope is that a central OS/2 repository will
> make it easier for others to join the project.

As long as it is Firefox, we should keep using their mercurial server. 
For the ESR branch it is,
http://hg.mozilla.org/releases/mozilla-esr10
Netlabs is limited to SVN while Mercurial (and Git) are much more 
powerful. Many of the projects currently hosted at netlabs are thinking 
of moving to github.
If we split off, I'd use bitbucket as it supports Mercurial. I already 
have the mzfntcfgft repository there, 
https://bitbucket.org/dryeo/mzfntcfgft. (readme needs updating for tip, 
we're currently using Gecko_10_release. If you want to build it, clone 
then hg update -r Gecko_10_Release)
>
> Either way, given all the work you are doing...you need help. So if we can split
> up the task into multiple ones (yeah, I understand not all the tasks can be
> divided up like that) hopefully the final goal of keeping Firefox in sync can
> get easier.
>
> In general, what is the best starting place for the developer willing to take a
> crack at the Firefox application? I'm assuming there is a lot of non-platform
> specific stuff out there to digest first before really getting into out platform
> specific details.
>

To start would be learning about Mercurial.
https://developer.mozilla.org/en-US/docs/Mercurial_basics
https://developer.mozilla.org/en-US/docs/Mercurial_Queues
https://developer.mozilla.org/en-US/docs/Mercurial_FAQ

I'll get documentation together on building the ESR branch which is a 
good start.
Dave
0
Dave
10/15/2012 12:12:32 AM
Felix Miata wrote:
> After boot and opening the essentials (FC/2 & XFile via startup folder,
> 2 DOS apps manually), FC/2 says I have 2,074,263,552 of 2,145,906,688
> free. Once a Gecko (normally SM 2.x, as I typically go weeks or even
> months without opening any FF on eCS) have dropped free below
> 1,500,000,000, I can expect a it/them to die in short order.

There's something wrong here. SeaMonkey shouldn't have problems when 
only using 500MBs. My SeaMonkey is currently using 628MBs and usually 
uses more. Of that most of the shared memory is in the high arena.
Perhaps the lack of programs that you're running is allowing SeaMonkey 
to run in low memory instead of high memory. You could look with Theseus 
or try to start something like Firefox first to allocate low memory. 
There is an application that does this but I don't remember the name.
What's your virtualaddresslimit set to?
Dave
0
Dave
10/15/2012 1:01:37 AM
On Mon, 15 Oct 2012 00:07:11 UTC, Felix Miata 
<UgaddaBkidding.due2UCE@dev.nul> wrote:

> On 2012-10-14 12:58 (GMT-0500) Doug Bissett composed:
> 
> > What makes you think that it is SM (or FF or TB) that is causing the
> > problem?
> 
> Other than PMView, which is only ever open while I'm actually using it, the 
> only "native" apps (I don't count FC/2 as a "native" app, while XFile is 
> tiny, inactive most of the time, and as prerequisite to critical WPS 
> functionality, I don't count it either) I've opened on eCS in the last half 
> decade are the Geckos. eCS is my all-important DOS, and until last month, it 
> was my primary/preferred access to the web.
> 
> After boot and opening the essentials (FC/2 & XFile via startup folder, 2 DOS 
> apps manually), FC/2 says I have 2,074,263,552 of 2,145,906,688 free. Once a 
> Gecko (normally SM 2.x, as I typically go weeks or even months without 
> opening any FF on eCS) have dropped free below 1,500,000,000, I can expect a 
> it/them to die in short order.

Now that is really strange. My 2 GB system usually has about 1.2 GB 
free, and almost always no more than 1.5 GB free, even without FF 
running. Of course, that has little bearing on how much shared memory 
is available. My guess would be, that you have something else that is 
using a lot of (probably low) shared memory, or, you have disabled, or
restricted, upper shared memory, somehow.

> SM 1.1.x would crash in the same free RAM area, but could go up to 8 days up 
> before dropping free RAM below the critical 1,500,000,000 level and dying. I 
> got in the habit of restarting at 6 day intervals to avoid history data loss 
> from crashing. Session restore allows me to much more conveniently restart 
> SM2 daily to avoid most crashes.

SM 1.x would probably use less memory, so it would take longer to get 
to your threshold (not sure why there would be one). Personally, I 
find Session Restore to be more of a pain, than useful, but that is 
probably because of the way that I use FF.

> I've not seen the 20,971,520 byte swap grown post-boot in several years, and 
> have no idea whether it's been used at all. Its time stamp only changes at 
> boot time.

My Swap file is 2 megs, and I never see it used.  I also have a laptop
with 1.5 GB of memory, and it never gets near to using the swap file. 
You would need to fill up real memory, before it would attempt to use 
the swap file.

> > This also begs the question: Why would you use more than 4 or 5 open
> > tabs? It must take longer to find an open tab, than to open a new one,
> > and close it when you are finished with it (just trying to understand
> > the logic of opening 50, or more, tabs, never mind having multiple SM,
> > and FF, programs open).
> 
> It's easier to find what I want time and time and time again in open tabs 
> than it is in bookmarks or history. Each window has its own group of tab 
> content types, rather like using pager or virtual desktops, keeping most easy 
> enough to locate. Plus, in a tab, there's no waiting unless I restart or care 
> for a reload, which frequently is exactly what I don't want to happen. Only 
> one profile/Gecko installation is allowed access to Flash content, minimizing 
> the possibility of crashes due to that abominable usability impediment.

I can't even imagine what you do with all of them, but I guess you 
have figured out what works for you.

> > I use FF, PMMail, and ProNews/2
> 
> I use SM because:
> 
> 1-it offers the same advantages of an integrated web suite that Netscape did

Personally, I never did understand why Netscape was done that way. A 
separerate browser, news, and mail program, makes more sense to me, 
and that is one of the main reasons why I jumped onto the FF amd TB 
bandwagon early in the game.  I see no advantage, at all, to using a 
single program for three different functions. In fact, I quickly 
abandoned TB too, simply because I like PMMail and ProNews/2 a lot 
better.

The biggest Mozilla "problem" is the DLL incompatibility, which RUN! 
looks after, with no messing around.

> 2-it's cross-platform, enabling me to support it for users of operating 
> systems installed on their puters when they bought them, which in turn
> 3-reduces slightly the number of people polluting the web via Outhouse and 
> Outbreak Excess

Well, 3 is a no brainer (I like to call it "Lookout Express"). I do a 
little of 2 myself, but if users want to use something else, that is 
up to them, and I make it clear that I don't know anything about what 
they want to use, so they are on their own. So far, only one guy has 
refused to change to FF, and TB (and he is the biggest problem that I 
have).

> Once upon a time I used ProNews/2, but only because of 
> https://bugzilla.mozilla.org/show_bug.cgi?id=60981


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

0
Doug
10/15/2012 2:45:23 AM
On 2012-10-14 18:01 (GMT-0700) Dave Yeo composed:

> Felix Miata wrote:

>> After boot and opening the essentials (FC/2 & XFile via startup folder,
>> 2 DOS apps manually), FC/2 says I have 2,074,263,552 of 2,145,906,688
>> free. Once a Gecko (normally SM 2.x, as I typically go weeks or even
>> months without opening any FF on eCS) have dropped free below
>> 1,500,000,000, I can expect a it/them to die in short order.

> There's something wrong here. SeaMonkey shouldn't have problems when
> only using 500MBs. My SeaMonkey is currently using 628MBs and usually
> uses more. Of that most of the shared memory is in the high arena.

I really don't pay much attention to RAM. I just see what FC/2 says 
occasionally, and have my suspicions whether it really has any idea what's 
going on in upper RAM space. I've never seen it report as low as 
1,399,999,999 free, and infrequently seen it very far below 1,500,000,000 
before SM dies.

IIRC its author migrated to Linux at least a half decade ago, which may mean 
he does little with it specific to OS/2, focusing more on keeping it building 
on OS/2 while working the feature set based on personal use on Linux and 
feedback from more Windows users than the others it's built for.

> Perhaps the lack of programs that you're running is allowing SeaMonkey
> to run in low memory instead of high memory. You could look with Theseus
> or try to start something like Firefox first to allocate low memory.
> There is an application that does this but I don't remember the name.

Right now on Linux I have SM 2.13.1, SM 2.14bX, FF 2.0.0.20, FF 3.6.28 & FF 
16.0.1 combined running well over 100 tabs, not including CZ in one SM and 
mailnews in the other, in addition to KPDF, Konq, File Commander, and several 
VC, Konsole & MC sessions. RAM used by basesystem, KDE and apps is about half 
of 4G, with the rest about evenly split between free and cache. Though I do 
have swap space on disk, I have it disabled. Linux isn't inept at using a lot 
of RAM. Its apps in those uncommon cases where crashing occurs, don't drive 
CPU to 100% or prevent access to uncrashed apps. The WPS has some nice 
features either exclusive or poorly shared by other desktops, but they've 
ceased to be worth the pain of having it be a primary or exclusive desktop 
environment. Linux sure isn't perfect, but it's easier, and less expensive, 
to live with. RAM utilization is a big reason why. Geckos being noticeably 
faster and non-crashing are other biggies. I keep using eCS now mostly 
because of its bulletproof, speedy and easy SVGA text DOS.

> What's your virtualaddresslimit set to?

Current is 1024, but I don't remember seeing any impact compared to 2048 or 
1536. This discussion does make me curious how behavior might change if I 
pulled the pair of 1024 sticks and put back the original pair of 256s.
-- 
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

  Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/
0
Felix
10/15/2012 6:09:02 AM
On Mon, 15 Oct 2012 06:09:02 UTC, Felix Miata 
<UgaddaBkidding.due2UCE@dev.nul> wrote:

> Current is 1024, but I don't remember seeing any impact compared to 2048 or 
> 1536.

For the record: It is suggested that 1536 is optimum, for most users. 
If you don't know any reason to use anything else, 1536 is probably 
the best for that setting. I suspect that it won't make any difference
to your immediate problem though.

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

0
Doug
10/15/2012 5:13:24 PM
On Mon, 15 Oct 2012 06:09:02 UTC, Felix Miata 
<UgaddaBkidding.due2UCE@dev.nul> wrote:

> I really don't pay much attention to RAM. I just see what FC/2 says 
> occasionally, and have my suspicions whether it really has any idea what's 
> going on in upper RAM space.

My guess is that FC/2 doesn't even know about upper shared memory 
space. In fact. it may even be possible that it blocks using upper 
shared memory space. Try running without it. At least get the version 
from 2011 at Hobbes (if you don't already have it):

> http://hobbes.nmsu.edu/download/pub/os2/util/shell/fc2_240.zip

Whether it fixes anything, or not, I don't know. I think that version 
simply makes the program available as freeware, but there is some 
indication that there are updates.

If you use eCenter (XCenter), use the Sentinal Memory Watcher widget 
to monitor memory usage. It doesn't split out shared, or upper, memory
usage, it just gives you the total available, what is currently being 
used, and how big the swap file is. That would seem to be slightly 
more information than what FC/2 gives you. You can also try Above512:

> http://hobbes.nmsu.edu/download/pub/os2/dev/util/above512_001b.zip

but it is not a dynamic thing. It may indicate whether FC/2 is 
interfering with the upper shared memory space though.

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

0
Doug
10/15/2012 5:13:25 PM
On 2012-10-15 12:13 (GMT-0500) Doug Bissett composed:

> On Mon, 15 Oct 2012 06:09:02 UTC, Felix Miata wrote:

>> I really don't pay much attention to RAM. I just see what FC/2 says
>> occasionally, and have my suspicions whether it really has any idea what's
>> going on in upper RAM space.

> My guess is that FC/2 doesn't even know about upper shared memory

That seems to be what I wrote, which I CC'd to its author separately.

> space. In fact. it may even be possible that it blocks using upper
> shared memory space. Try running without it. At least get the version

I can't get anything done without it. Any system without at least one running 
OFM to me is all but useless.

> from 2011 at Hobbes (if you don't already have it):

>> http://hobbes.nmsu.edu/download/pub/os2/util/shell/fc2_240.zip

Mine is probably newer, 2.41-dev. I chose latest stable devel from 
http://silk.apana.org.au/fc2development.html long ago. On Linux I'm at 2.40 
because the repos don't seem to have either devel option available.

> If you use eCenter (XCenter), use the Sentinal Memory Watcher widget

I only use WarpCenter set to show activity.

> to monitor memory usage. It doesn't split out shared, or upper, memory
> usage, it just gives you the total available, what is currently being
> used, and how big the swap file is. That would seem to be slightly
> more information than what FC/2 gives you. You can also try Above512:

>> http://hobbes.nmsu.edu/download/pub/os2/dev/util/above512_001b.zip

With only the CZ component of SM running since my last thread post, FC/2 
shows 1,807,663,104 free of 2,145,906,688. Above512, with or without the -b 
option, says:

ABOVE512.exe  LX format 32bit DLL module 'loading above 512MB' marking utility,
   version 0.01b (internal/experimental use only)
....
current free virtual address space in kB (private / shared):
   310720 / 185728 below 512MB line, 454464 / 192072 above 512MB line

Subsequently opening browser window to same 12 tab group as when last closed 
brings FC/2 report down to 1,749,024,768, and last lines of above512 to:

current free virtual address space in kB (private / shared):
   310720 / 185600 below 512MB line, 454464 / 145252 above 512MB line

Then I downloaded and unzipped 
http://silk.apana.org.au/pub/fc2/fc2_250-dev.zip, copied the old fc.ini file 
to the unpacked location, closed FC/2, opened a command prompt window, and 
started 2.50-dev in that window. Free now shows 1,720,237,184, and above512:

current free virtual address space in kB (private / shared):
   310720 / 186112 below 512MB line, 454464 / 145252 above 512MB line
-- 
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

  Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/
0
Felix
10/15/2012 7:20:55 PM
On 14.10.12 02.49, Dave Yeo wrote:

hello dave,

> The OS/2 builds are so far behind due to lack of developers. I can build
> newer versions but they crash if there are any add-ons, often breaking

maybe there should be a big note somewhere that these build are ESR 
build from the long time stable branch. They wont add new features but 
will get security updates like the other builds.

> I'm doing this volunteerly as I also like an up to date browser and it
> can be interesting but the rapid release schedule really calls for full
> time developer(s).

agreed. Its nice that you were building all these ESR versions as these 
rapid release versions are quite too quickly released. It will add new 
features and problems that can't be fixed quickly  before it will get 
replaces by again a newer version. The goal should be the next ESR 
branch that is based on the 17.xx code level.


-- 
cheers
mozilla_test
0
mozilla_test
10/15/2012 8:16:11 PM
On 10/15/2012 1:16 PM, mozilla_test wrote:

> maybe there should be a big note somewhere that these build are ESR
> build from the long time stable branch. They wont add new features but
> will get security updates like the other builds.

Where do you see the announcements for these where it does not say that 
already?

0
Steve
10/15/2012 8:30:56 PM
On Mon, 15 Oct 2012 19:20:55 UTC, Felix Miata 
<UgaddaBkidding.due2UCE@dev.nul> wrote:

> On 2012-10-15 12:13 (GMT-0500) Doug Bissett composed:
> 
> > On Mon, 15 Oct 2012 06:09:02 UTC, Felix Miata wrote:
> 
> >> I really don't pay much attention to RAM. I just see what FC/2 says
> >> occasionally, and have my suspicions whether it really has any idea what's
> >> going on in upper RAM space.
> 
> > My guess is that FC/2 doesn't even know about upper shared memory
> 
> That seems to be what I wrote, which I CC'd to its author separately.
> 
> > space. In fact. it may even be possible that it blocks using upper
> > shared memory space. Try running without it. At least get the version
> 
> I can't get anything done without it. Any system without at least one running 
> OFM to me is all but useless.
> 
> > from 2011 at Hobbes (if you don't already have it):
> 
> >> http://hobbes.nmsu.edu/download/pub/os2/util/shell/fc2_240.zip
> 
> Mine is probably newer, 2.41-dev. I chose latest stable devel from 
> http://silk.apana.org.au/fc2development.html long ago. On Linux I'm at 2.40 
> because the repos don't seem to have either devel option available.

Okay. It was just a thought...

> > If you use eCenter (XCenter), use the Sentinal Memory Watcher widget
> 
> I only use WarpCenter set to show activity.

You do realize, that WarpCenter (apparently) has some bugs that can 
cause problems like you describe? (Hangs, and crashes). I have never 
heard of any free, or used, memory related problems (but that doesn't 
mean they don't exist).

> > to monitor memory usage. It doesn't split out shared, or upper, memory
> > usage, it just gives you the total available, what is currently being
> > used, and how big the swap file is. That would seem to be slightly
> > more information than what FC/2 gives you. You can also try Above512:
> 
> >> http://hobbes.nmsu.edu/download/pub/os2/dev/util/above512_001b.zip
> 
> With only the CZ component of SM running since my last thread post, FC/2 
> shows 1,807,663,104 free of 2,145,906,688. Above512, with or without the -b 
> option, says:
> 
> ABOVE512.exe  LX format 32bit DLL module 'loading above 512MB' marking utility,
>    version 0.01b (internal/experimental use only)
> ...
> current free virtual address space in kB (private / shared):
>    310720 / 185728 below 512MB line, 454464 / 192072 above 512MB line
> 
> Subsequently opening browser window to same 12 tab group as when last closed 
> brings FC/2 report down to 1,749,024,768, and last lines of above512 to:
> 
> current free virtual address space in kB (private / shared):
>    310720 / 185600 below 512MB line, 454464 / 145252 above 512MB line
>
> Then I downloaded and unzipped 
> http://silk.apana.org.au/pub/fc2/fc2_250-dev.zip, copied the old fc.ini file 
> to the unpacked location, closed FC/2, opened a command prompt window, and 
> started 2.50-dev in that window. Free now shows 1,720,237,184, and above512:
> 
> current free virtual address space in kB (private / shared):
>    310720 / 186112 below 512MB line, 454464 / 145252 above 512MB line

Hmmm. That indicates that there is plenty of memory available. I guess
you would need to try Above512 when you are near the critical 1.5 GB 
free, to see what changes, if anything. If nothing significant comes 
from that, I think you need to look in a different direction. 
Something else must be causing the problem (which would not surprise 
me, at all). The big question is "what can do that?"

BTW, I downloaded FC2 240, and had a quick look. It doesn't seem to 
cause any problems, but I only looked briefly. I doubt if the free 
memory indication might be an indicator of pending problems, but I 
will need to play with it a lot more before saying yes or no. The free
memory number seems to be just a number that is easily derived by 
asking the system how much free memory it has (there would be no other
meaning). How that could possibly indicate a pending problem, I don't 
know. I suspect that it is a side effect of the real problem, or 
coincidence.

Would you consider sending me a copy of your CONFIG.SYS (remove any 
passwords, or other sensitive stuff, that may be in it)? I wrote, and 
maintain, LCSS (Logical Config.SYS Sort - at HOBBES), and I suspect 
that your CONFIG.SYS may contain some things that I am missing in my 
database. I may also be able to spot something that might cause a 
problem. 

Which version of eCS or OS/2, and FP level, are you using?

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

0
Doug
10/15/2012 9:47:48 PM
On 10/15/2012 2:47 PM, Doug Bissett wrote:

> You do realize, that WarpCenter (apparently) has some bugs that can
> cause problems like you describe? (Hangs, and crashes).

First I've heard of such a thing... I don't have any problems like that.

0
Steve
10/15/2012 11:06:47 PM
On Mon, 15 Oct 2012 00:12:32 UTC, Dave Yeo <dave.r.yeo@gmail.com> wrote:

> Dariusz Piatkowski wrote:
> > On Sun, 14 Oct 2012 20:58:25 UTC, Dave Yeo<dave.r.yeo@gmail.com>  wrote:
> >
> >> Dariusz Piatkowski wrote:
> >>> Yes, the page Steve posted was the original information I had looked at. Now
> >>> given the input you provided Dave what can be done to allow additional folks
> >>> like myself to come in an contribute?
> >>
> >> We've fallen far behind and probably need a couple of months of
> >> developer time to get caught up.
> >
> >
> > Point out what I/we (others interested in this, Al F. comes to mind as he's
> > responding to the thread) can help out with...even the simplest of things...
> >
> >
> >>> Sooo....is there anyone in the OS/2 Firefox team (who is the team btw?, is there
> >>> a Netlabs like project site?) that could take on the process to re-fresh the
> >>> 'involvement roadmap'? I would be happy/thrilled to work with this person as the
> >>> lab rat! ;-)
> >>
> >> Currently I'm all there is in the way of a Firefox team. No project site
> >> or anything else currently
> >> Dave
> >
> >
> > OK, so would it be possible to move the project to something like Netlabs? I
> > only suggest that b/c there seems to be a 'nice' interface to it. I know nothing
> > about Netlabs beyond this, I know nothing about any of the internal politics
> > (are there any???), etc, etc... My hope is that a central OS/2 repository will
> > make it easier for others to join the project.
> 
> As long as it is Firefox, we should keep using their mercurial server. 
> For the ESR branch it is,
> http://hg.mozilla.org/releases/mozilla-esr10
> Netlabs is limited to SVN while Mercurial (and Git) are much more 
> powerful. Many of the projects currently hosted at netlabs are thinking 
> of moving to github.
> If we split off, I'd use bitbucket as it supports Mercurial. I already 
> have the mzfntcfgft repository there, 
> https://bitbucket.org/dryeo/mzfntcfgft. (readme needs updating for tip, 
> we're currently using Gecko_10_release. If you want to build it, clone 
> then hg update -r Gecko_10_Release)
> >
> > Either way, given all the work you are doing...you need help. So if we can split
> > up the task into multiple ones (yeah, I understand not all the tasks can be
> > divided up like that) hopefully the final goal of keeping Firefox in sync can
> > get easier.
> >
> > In general, what is the best starting place for the developer willing to take a
> > crack at the Firefox application? I'm assuming there is a lot of non-platform
> > specific stuff out there to digest first before really getting into out platform
> > specific details.
> >
> 
> To start would be learning about Mercurial.
> https://developer.mozilla.org/en-US/docs/Mercurial_basics
> https://developer.mozilla.org/en-US/docs/Mercurial_Queues
> https://developer.mozilla.org/en-US/docs/Mercurial_FAQ
> 
> I'll get documentation together on building the ESR branch which is a 
> good start.
> Dave


OK, lots of good reading...thank you...I've started on this...will be looking 
for further FYIs regarding the udpated OS/2 docs.

Thank you Dave!

0
Dariusz
10/16/2012 2:36:57 AM
Dariusz Piatkowski wrote:
> I'll get documentation together on building the ESR branch which is a
>>  good start.

I've uploaded gecko10_09_patches.zip to netlabs. Includes everything 
needed besides the source I hope including a quick build.txt. Forgive my 
crappy writing skills :)
One thing I did forget to mention is the patches have to have Unix line 
endings to apply, IIRC unzip by default will add cr to the line endings. 
Of course the REXX scripts do need DOS line endings and there are a 
couple in the source that may need converting.
Dave
0
Dave
10/16/2012 4:43:58 AM
On 15.10.12 21.30, Steve Wendt wrote:

> Where do you see the announcements for these where it does not say that
> already?

hello,
more inside the application.. despite the zip file naming people wont 
notice, e.g. only the about dialog in firefox will tell ESR but not in 
seamonkey and thunderbird.

-- 
cheers
mozilla_test
0
mozilla_test
10/16/2012 8:56:26 PM
On 10/16/2012 1:56 PM, mozilla_test wrote:

> more inside the application.. despite the zip file naming people wont
> notice, e.g. only the about dialog in firefox will tell ESR but not in
> seamonkey and thunderbird.

SeaMonkey doesn't support ESR; not sure why Thunderbird doesn't indicate it.

0
Steve
10/16/2012 9:01:04 PM
On Tue, 16 Oct 2012 04:43:58 UTC, Dave Yeo <dave.r.yeo@gmail.com> 
wrote:

> Dariusz Piatkowski wrote:
> > I'll get documentation together on building the ESR branch which is a
> >>  good start.
> 
> I've uploaded gecko10_09_patches.zip to netlabs. Includes everything 
> needed besides the source I hope including a quick build.txt. Forgive my 
> crappy writing skills :)
> One thing I did forget to mention is the patches have to have Unix line 
> endings to apply, IIRC unzip by default will add cr to the line endings. 
> Of course the REXX scripts do need DOS line endings and there are a 
> couple in the source that may need converting.
> Dave
Which HG are you using?  I have been trying to pull again and blast if
I am not having troubles with Mercurial once more.  CVS just worked, 
SVN just works but I see nothing but hassles from Mercurial.
Andy

-- 

0
Andy
10/16/2012 9:56:24 PM
Andy wrote:
> On Tue, 16 Oct 2012 04:43:58 UTC, Dave Yeo<dave.r.yeo@gmail.com>
> wrote:
>
>> Dariusz Piatkowski wrote:
>>> I'll get documentation together on building the ESR branch which is a
>>>>   good start.
>>
>> I've uploaded gecko10_09_patches.zip to netlabs. Includes everything
>> needed besides the source I hope including a quick build.txt. Forgive my
>> crappy writing skills :)
>> One thing I did forget to mention is the patches have to have Unix line
>> endings to apply, IIRC unzip by default will add cr to the line endings.
>> Of course the REXX scripts do need DOS line endings and there are a
>> couple in the source that may need converting.
>> Dave
> Which HG are you using?  I have been trying to pull again and blast if
> I am not having troubles with Mercurial once more.  CVS just worked,
> SVN just works but I see nothing but hassles from Mercurial.
> Andy
>

I've used Andy's build, Paul's 2.6.2 and currently use one installed by 
RPM, python-2.6.5-3.oc00.i386.rpm with matching library and 
mercurial-1.6.3-2.oc00.i386.
I use the newer due to it working for pushing to a https repo and once 
using it you can't go back though I can't remember exactly why now.
Dave
0
Dave
10/17/2012 2:13:23 AM
On Mon, 15 Oct 2012 21:47:48 UTC, "Doug Bissett" 
<dougb007!SPAM@telus.net> wrote:

> On Mon, 15 Oct 2012 19:20:55 UTC, Felix Miata 
> <UgaddaBkidding.due2UCE@dev.nul> wrote:
> 
> > On 2012-10-15 12:13 (GMT-0500) Doug Bissett composed:
> > 
> > > On Mon, 15 Oct 2012 06:09:02 UTC, Felix Miata wrote:
> > 
> > >> I really don't pay much attention to RAM. I just see what FC/2 says
> > >> occasionally, and have my suspicions whether it really has any idea what's
> > >> going on in upper RAM space.
> > 
> > > My guess is that FC/2 doesn't even know about upper shared memory
> > 
> > That seems to be what I wrote, which I CC'd to its author separately.
> > 
> > > space. In fact. it may even be possible that it blocks using upper
> > > shared memory space. Try running without it. At least get the version
> > 
> > I can't get anything done without it. Any system without at least one running 
> > OFM to me is all but useless.
> > 
> > > from 2011 at Hobbes (if you don't already have it):
> > 
> > >> http://hobbes.nmsu.edu/download/pub/os2/util/shell/fc2_240.zip
> > 
> > Mine is probably newer, 2.41-dev. I chose latest stable devel from 
> > http://silk.apana.org.au/fc2development.html long ago. On Linux I'm at 2.40 
> > because the repos don't seem to have either devel option available.
> 
> Okay. It was just a thought...
> 
> > > If you use eCenter (XCenter), use the Sentinal Memory Watcher widget
> > 
> > I only use WarpCenter set to show activity.
> 
> You do realize, that WarpCenter (apparently) has some bugs that can 
> cause problems like you describe? (Hangs, and crashes). I have never 
> heard of any free, or used, memory related problems (but that doesn't 
> mean they don't exist).
> 
> > > to monitor memory usage. It doesn't split out shared, or upper, memory
> > > usage, it just gives you the total available, what is currently being
> > > used, and how big the swap file is. That would seem to be slightly
> > > more information than what FC/2 gives you. You can also try Above512:
> > 
> > >> http://hobbes.nmsu.edu/download/pub/os2/dev/util/above512_001b.zip
> > 
> > With only the CZ component of SM running since my last thread post, FC/2 
> > shows 1,807,663,104 free of 2,145,906,688. Above512, with or without the -b 
> > option, says:
> > 
> > ABOVE512.exe  LX format 32bit DLL module 'loading above 512MB' marking utility,
> >    version 0.01b (internal/experimental use only)
> > ...
> > current free virtual address space in kB (private / shared):
> >    310720 / 185728 below 512MB line, 454464 / 192072 above 512MB line
> > 
> > Subsequently opening browser window to same 12 tab group as when last closed 
> > brings FC/2 report down to 1,749,024,768, and last lines of above512 to:
> > 
> > current free virtual address space in kB (private / shared):
> >    310720 / 185600 below 512MB line, 454464 / 145252 above 512MB line
> >
> > Then I downloaded and unzipped 
> > http://silk.apana.org.au/pub/fc2/fc2_250-dev.zip, copied the old fc.ini file 
> > to the unpacked location, closed FC/2, opened a command prompt window, and 
> > started 2.50-dev in that window. Free now shows 1,720,237,184, and above512:
> > 
> > current free virtual address space in kB (private / shared):
> >    310720 / 186112 below 512MB line, 454464 / 145252 above 512MB line
> 
> Hmmm. That indicates that there is plenty of memory available. I guess
> you would need to try Above512 when you are near the critical 1.5 GB 
> free, to see what changes, if anything. If nothing significant comes 
> from that, I think you need to look in a different direction. 
> Something else must be causing the problem (which would not surprise 
> me, at all). The big question is "what can do that?"
> 
> BTW, I downloaded FC2 240, and had a quick look. It doesn't seem to 
> cause any problems, but I only looked briefly. I doubt if the free 
> memory indication might be an indicator of pending problems, but I 
> will need to play with it a lot more before saying yes or no. The free
> memory number seems to be just a number that is easily derived by 
> asking the system how much free memory it has (there would be no other
> meaning). How that could possibly indicate a pending problem, I don't 
> know. I suspect that it is a side effect of the real problem, or 
> coincidence.
> 
> Would you consider sending me a copy of your CONFIG.SYS (remove any 
> passwords, or other sensitive stuff, that may be in it)? I wrote, and 
> maintain, LCSS (Logical Config.SYS Sort - at HOBBES), and I suspect 
> that your CONFIG.SYS may contain some things that I am missing in my 
> database. I may also be able to spot something that might cause a 
> problem. 
> 
> Which version of eCS or OS/2, and FP level, are you using?
> 

For the record. It seems that FM is still using excphead.sys, which 
was deprecated years ago. He is also running eCS 1.1, and he is still 
using CLKBASIC, which is known to have problems. I don't know if 
either one could cause the described problems though. He also had the 
SMSTART.EXE line in CONFIG.SYS. Again, I don't know if that can cause 
such problems, but it is generally advisable to REM that line.

I guess we wait to see what the results are...

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

0
Doug
10/17/2012 3:40:25 AM
On 10/16/2012 8:40 PM, Doug Bissett wrote:

> excphead.sys, which  was deprecated years ago

Is that the hack that prevents SIO2K from trapping?

0
Steve
10/17/2012 5:27:15 PM
On 16.10.12 22.01, Steve Wendt wrote:
>
> SeaMonkey doesn't support ESR; not sure why Thunderbird doesn't indicate
> it.

true, theres no official ESR for the seamonkey project, because of that 
its nice that dave releases them as well for OS/2 as I mainly use seamonkey.

-- 
cheers
mozilla_test
0
mozilla_test
10/17/2012 6:50:10 PM
On 2012-10-16 22:40 (GMT-0500) Doug Bissett composed:

> For the record. It seems that FM is still using excphead.sys, which
> was deprecated years ago. He is also running eCS 1.1, and he is still

To say that without more is misleading:
Directory of F:\

  8-11-05 11:50a       849,262     54 ashr  OS2KRNL
  8-11-05 11:50a       849,262     54 ashr  OS2KRNL.14104a

F:\OS2\INSTALL\SYSLEVEL.BDD
IBM OS/2 Base Device Drivers
Version 4.52     Component ID 5639A6101
Type 0C
Current CSD level: XR0D003
Prior   CSD level: XR04503

F:\OS2\INSTALL\SYSLEVEL.ECS
eComStation Operating System 1.1
Version 1.10     Component ID 5639A6101
Type 0C
Current CSD level: XR0C004
Prior   CSD level: XR04502

F:\OS2\INSTALL\SYSLEVEL.FPK
OS/2 Convenience Package Service Level
Version 1.00     Component ID 566933010
Type Fixpak
Current CSD level: XR0C004
Prior   CSD level: XR0C004

F:\OS2\INSTALL\SYSLEVEL.OS2
Convenience Package - OS/2 Warp 4 Base Operating System
Version 4.52     Component ID 5639A6101
Type 0C
Current CSD level: XR0C004
Prior   CSD level: XR04503

The way I remember at the time I got my 1.2 package, there really wasn't 
enough difference between 1.2 and what I call mine, 1.14, to justify a fresh 
installation of 1.2. 2.0 was rather more inviting, but I just never got the 
urge. I quit renewing the subscription a year before 2.0 release.

> using CLKBASIC, which is known to have problems. I don't know if
> either one could cause the described problems though. He also had the
> SMSTART.EXE line in CONFIG.SYS. Again, I don't know if that can cause
> such problems, but it is generally advisable to REM that line.

> I guess we wait to see what the results are...

Too early to tell much yet since only about 22 hours since reboot with these 
CONFIG.SYS changes:

-device=F:\os2\boot\excphead.sys
+REM device=F:\os2\boot\excphead.sys
-RUN=F:\OS2\SMSTART.EXE
+REM RUN=F:\OS2\SMSTART.EXE
-CALL=F:\OS2\CACHEF32.EXE /L:OFF /F
+REM CALL=F:\OS2\CACHEF32.EXE /L:OFF /F
-- 
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

  Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/
0
Felix
10/17/2012 8:34:26 PM
On Wed, 17 Oct 2012 20:34:26 UTC, Felix Miata 
<UgaddaBkidding.due2UCE@dev.nul> wrote:

> On 2012-10-16 22:40 (GMT-0500) Doug Bissett composed:
> 
> > For the record. It seems that FM is still using excphead.sys, which
> > was deprecated years ago. He is also running eCS 1.1, and he is still
> 
> To say that without more is misleading:
> Directory of F:\
> 
>   8-11-05 11:50a       849,262     54 ashr  OS2KRNL
>   8-11-05 11:50a       849,262     54 ashr  OS2KRNL.14104a
> 
> F:\OS2\INSTALL\SYSLEVEL.BDD
> IBM OS/2 Base Device Drivers
> Version 4.52     Component ID 5639A6101
> Type 0C
> Current CSD level: XR0D003
> Prior   CSD level: XR04503
> 
> F:\OS2\INSTALL\SYSLEVEL.ECS
> eComStation Operating System 1.1
> Version 1.10     Component ID 5639A6101
> Type 0C
> Current CSD level: XR0C004
> Prior   CSD level: XR04502
> 
> F:\OS2\INSTALL\SYSLEVEL.FPK
> OS/2 Convenience Package Service Level
> Version 1.00     Component ID 566933010
> Type Fixpak
> Current CSD level: XR0C004
> Prior   CSD level: XR0C004
> 
> F:\OS2\INSTALL\SYSLEVEL.OS2
> Convenience Package - OS/2 Warp 4 Base Operating System
> Version 4.52     Component ID 5639A6101
> Type 0C
> Current CSD level: XR0C004
> Prior   CSD level: XR04503
> 
> The way I remember at the time I got my 1.2 package, there really wasn't 
> enough difference between 1.2 and what I call mine, 1.14, to justify a fresh 
> installation of 1.2. 2.0 was rather more inviting, but I just never got the 
> urge. I quit renewing the subscription a year before 2.0 release.
> 
> > using CLKBASIC, which is known to have problems. I don't know if
> > either one could cause the described problems though. He also had the
> > SMSTART.EXE line in CONFIG.SYS. Again, I don't know if that can cause
> > such problems, but it is generally advisable to REM that line.
> 
> > I guess we wait to see what the results are...
> 
> Too early to tell much yet since only about 22 hours since reboot with these 
> CONFIG.SYS changes:
> 
> -device=F:\os2\boot\excphead.sys
> +REM device=F:\os2\boot\excphead.sys
> -RUN=F:\OS2\SMSTART.EXE
> +REM RUN=F:\OS2\SMSTART.EXE
> -CALL=F:\OS2\CACHEF32.EXE /L:OFF /F
> +REM CALL=F:\OS2\CACHEF32.EXE /L:OFF /F

Actually, There is one more change that you should make: Add the line 
DLLBASING=OFF
near the top of your CONFIG.SYS. That slows the system (it might be 
noticable on a 386 SX processor), but allows it to make better use of 
the shared memory space. Of course, that won't take effect until you 
reboot.

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

0
Doug
10/18/2012 5:12:15 AM
On Wed, 17 Oct 2012 17:27:15 UTC, Steve Wendt <spamsux@forgetit.org> 
wrote:

> On 10/16/2012 8:40 PM, Doug Bissett wrote:
> 
> > excphead.sys, which  was deprecated years ago
> 
> Is that the hack that prevents SIO2K from trapping?

It might have been for that. I know that later kernels have the fix. 
Everybody should be using 14.104a, or better, by now.

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

0
Doug
10/18/2012 5:12:15 AM
Dariusz,

just to let you know, i have a psi 0.15 build almost done. So don't 
waste time on it :)

regards
Silvan

Dariusz Piatkowski wrote:
> Hi Dave!
> 
> 
> On Sun, 14 Oct 2012 01:49:37 UTC, Dave Yeo <dave.r.yeo@gmail.com> wrote:
> 
> 
>>>Why are the OS/2 levels so far behind? There are no dates on these
>>>levels so there is no way to put a time frame around these newer levels.
>>
>>The OS/2 builds are so far behind due to lack of developers. I can build 
>>newer versions but they crash...
>>Dave
> 
> 
> 
> So how the heck do the rest of us get involved? I had previously asked this 
> question, received some pointers...spent some time looking into the project and 
> quite frankly, was completely lost!!!
> 
> The code complexity is one thing, but the overall OS/2 framework, what resources
> such as compiler, libraries, tools to use is nothing but a major brick wall. Is 
> there not a document somewhere which spells out, one by one, how a given OS/2 
> machine needs to be set up? Is there not a downloadable environment that could 
> be utilized which is already pre-configured?
> 
> In my case, I have my daily use machine (which is SMP configured and is very 
> fast for just about everything I ask it to do). I also have my old hardware 
> still kicking around with a complete OS/2 environment setup that could be used 
> as a spare box to do work with. Effectively, that means as a developer (I'm an 
> IS professional by trade and spent a few years wearing exactly those shoes) I 
> have my build & test boxes readily available to me. 
> 
> Given the rather steep climb on the Firefox project I have now started looking 
> at the QT framework in hopes of compiling the new version of PSI IM client. Will
> it work? ....no idea...but you've got to try to know.
> 
> I would much rather devote my time to something like Firefox, but again, much 
> help is needed to get started...
0
Silvan
10/18/2012 10:05:52 AM
On Thu, 18 Oct 2012 00:12:15 -0500, Doug Bissett <dougb007!SPAM@telus.net>
wrote:

> Actually, There is one more change that you should make: Add the line 
> DLLBASING=OFF
> near the top of your CONFIG.SYS.

Shouldn't that be "SET DLLBASING=OFF"

<runs away guffawing>
0
Paul
10/18/2012 11:57:00 AM
On Thu, 18 Oct 2012 11:57:00 UTC, Paul Ratcliffe 
<abuse@orac12.clara34.co56.uk78> wrote:

> On Thu, 18 Oct 2012 00:12:15 -0500, Doug Bissett <dougb007!SPAM@telus.net>
> wrote:
> 
> > Actually, There is one more change that you should make: Add the line 
> > DLLBASING=OFF
> > near the top of your CONFIG.SYS.
> 
> Shouldn't that be "SET DLLBASING=OFF"
> 
> <runs away guffawing>

Showing your ignorance again Paul?

To be clear, and prevent confusion, NO it does NOT use SET.

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

0
Doug
10/18/2012 3:38:51 PM
On 2012-10-18 00:12 (GMT-0500) Doug Bissett composed:

> Actually, There is one more change that you should make: Add the line
> DLLBASING=OFF
> near the top of your CONFIG.SYS. That slows the system (it might be
> noticable on a 386 SX processor), but allows it to make better use of
> the shared memory space. Of course, that won't take effect until you
> reboot.

SM crashed at about 40 hours even though I never did anything in the browser 
window and did very little in the CZ window. Now I've booted with 
DLLBASING=OFF to try again.
-- 
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

  Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/
0
Felix
10/18/2012 8:33:01 PM
On 2012-10-18 00:12 (GMT-0500) Doug Bissett composed:

> Actually, There is one more change that you should make: Add the line
> DLLBASING=OFF
> near the top of your CONFIG.SYS. That slows the system (it might be
> noticable on a 386 SX processor), but allows it to make better use of
> the shared memory space. Of course, that won't take effect until you
> reboot.

SM crashed at about 40 hours even though I never did anything in the browser 
window and did very little in the CZ window. Now I've booted with 
DLLBASING=OFF to try again.
-- 
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

  Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/
0
Felix
10/18/2012 8:33:23 PM
On 10/18/2012 1:33 PM, Felix Miata wrote:

> SM crashed at about 40 hours

Do you have exceptq?  Is there a trap file?

0
Steve
10/18/2012 9:00:53 PM
On 2012-10-18 14:00 (GMT-0700) Steve Wendt composed:

> Felix Miata wrote:

>> SM crashed at about 40 hours

> Do you have exceptq?  Is there a trap file?

http://fm.no-ip.com/Tmp/005b_01trp.txt ?
http://fm.no-ip.com/Tmp/popuplog-e-965os2.txt ?
-- 
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

  Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/
0
Felix
10/18/2012 9:37:55 PM
On 10/18/2012 2:37 PM, Felix Miata wrote:

>> Do you have exceptq?  Is there a trap file?
>
> http://fm.no-ip.com/Tmp/005b_01trp.txt ?

That tells me libc065 is crashing due to some font code.  Do you have 
Innotek's FT2LIB enabled for SeaMonkey?  If so, that could possibly be 
the cause.

0
Steve
10/18/2012 9:59:28 PM
On 2012-10-18 14:59 (GMT-0700) Steve Wendt composed:

> Felix Miata wrote:

>> http://fm.no-ip.com/Tmp/005b_01trp.txt ?

> That tells me libc065 is crashing due to some font code.  Do you have
> Innotek's FT2LIB enabled for SeaMonkey?  If so, that could possibly be
> the cause.

It's enabled for nosuchapp.exe, seamonkey1.exe, firefox2.exe & pmshell.exe.
-- 
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

  Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/
0
Felix
10/18/2012 10:04:24 PM
On 10/18/2012 3:04 PM, Felix Miata wrote:

>> That tells me libc065 is crashing due to some font code.  Do you have
>> Innotek's FT2LIB enabled for SeaMonkey?  If so, that could possibly be
>> the cause.
>
> It's enabled for nosuchapp.exe, seamonkey1.exe, firefox2.exe & pmshell.exe.

Is it version 2.4 or 2.6b?  I know they have mentioned "known problems" 
using it for PMShell, but I don't know details.  Version 2.6b seems more 
stable to me, but it requires some beta version of libc06 (b4?) and I 
don't use it for PMShell myself.

0
Steve
10/18/2012 11:10:25 PM
On Thu, 18 Oct 2012 10:38:51 -0500, Doug Bissett <dougb007!SPAM@telus.net>
wrote:

>> > Actually, There is one more change that you should make: Add the line 
>> > DLLBASING=OFF
>> > near the top of your CONFIG.SYS.
>> 
>> Shouldn't that be "SET DLLBASING=OFF"
>> 
>> <runs away guffawing>
> 
> Showing your ignorance again Paul?

No, just teasing you unmercilessly. I guess it went over your head.
"Whoosh" as they say.
0
Paul
10/18/2012 11:30:24 PM
On 2012-10-18 16:10 (GMT-0700) Steve Wendt composed:

> Is it version 2.4 or 2.6b?  I know they have mentioned "known problems"
> using it for PMShell, but I don't know details.  Version 2.6b seems more
> stable to me, but it requires some beta version of libc06 (b4?) and I
> don't use it for PMShell myself.

I had no luck figuring out what zip it came from. I'm pretty sure it's 2.6b.

Directory of F:\os2\dll
  2-01-05  1:15p       421,348      0 a---  ft2lib.dll
Directory of F:\emx\dll
  7-25-03  6:13p       204,950     54 a---  libc01.dll
  8-19-03  2:13p       207,153      0 a---  libc02.dll
  9-12-03  2:59p       208,753      0 a---  libc03.dll
10-27-03  5:13p       230,785      0 a---  libc04.dll
  4-14-04  4:37p       356,330      0 a---  libc05.dll
  3-23-12  4:32a        48,142      0 a---  libc06.dll
  3-23-12  4:32a        48,142      0 a---  libc061.dll
  3-23-12  4:32a       157,124      0 a---  libc062.dll
  3-23-12  4:32a       157,124      0 a---  libc063.dll
  3-23-12  4:32a       157,176      0 a---  libc064.dll
  8-11-08  5:53a     1,353,252      0 a---  libc064x.dll
  3-23-12  4:32a     1,353,208      0 a---  libc065.dll
  3-15-05 11:26a       562,712     65 a---  libc06b4.dll
-- 
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

  Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/
0
Felix
10/18/2012 11:55:31 PM
Felix Miata wrote:
> On 2012-10-18 14:59 (GMT-0700) Steve Wendt composed:
>
>> Felix Miata wrote:
>
>>> http://fm.no-ip.com/Tmp/005b_01trp.txt ?
>
>> That tells me libc065 is crashing due to some font code. Do you have
>> Innotek's FT2LIB enabled for SeaMonkey? If so, that could possibly be
>> the cause.
>
> It's enabled for nosuchapp.exe, seamonkey1.exe, firefox2.exe & pmshell.exe.

Disable it. Especially for newer Mozilla apps which have their own 
anti-aliasing.

Dave
0
Dave
10/19/2012 1:01:38 AM
On 2012-10-18 18:01 (GMT-0700) Dave Yeo composed:

>>> That tells me libc065 is crashing due to some font code. Do you have
>>> Innotek's FT2LIB enabled for SeaMonkey? If so, that could possibly be
>>> the cause.

>> It's enabled for nosuchapp.exe, seamonkey1.exe, firefox2.exe & pmshell.exe.

> Disable it. Especially for newer Mozilla apps which have their own
> anti-aliasing.

For which? Only one on that list has been opened in the past 6 months, and it 
isn't any Mozilla.
-- 
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

  Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/
0
Felix
10/19/2012 1:05:36 AM
Felix Miata wrote:
> On 2012-10-18 18:01 (GMT-0700) Dave Yeo composed:
>
>>>> That tells me libc065 is crashing due to some font code. Do you have
>>>> Innotek's FT2LIB enabled for SeaMonkey? If so, that could possibly be
>>>> the cause.
>
>>> It's enabled for nosuchapp.exe, seamonkey1.exe, firefox2.exe &
>>> pmshell.exe.
>
>> Disable it. Especially for newer Mozilla apps which have their own
>> anti-aliasing.
>
> For which? Only one on that list has been opened in the past 6 months,
> and it isn't any Mozilla.

Try renaming ft2lib.dll (you'll need to unlock it).
Your crashes in nspr4 seem to be in PR_MD_WAIT_CV so those sys3170's 
seems to be crashing while waiting for a thread.
Would be interesting to see the trap with libc065.xqs which can be 
created by downloading the exceptq71-dev package (Hobbes) and running 
mzpxqs on the libc065 map file. All the libc functions in your trp file 
seem to be related to [de]allocating high memory with it being called by 
Freetype.
One guess is that you have a font installed that is stressing out 
freetype in a way that no-one else has experienced. Another guess is 
that you have a lot of fonts installed and something is overflowing as 
the font list is rebuilt over and over.
Dave

0
Dave
10/19/2012 3:25:15 AM
On 2012-10-18 20:25 (GMT-0700) Dave Yeo composed:

> Felix Miata wrote:

>> On 2012-10-18 18:01 (GMT-0700) Dave Yeo composed:

>>>>> That tells me libc065 is crashing due to some font code. Do you have
>>>>> Innotek's FT2LIB enabled for SeaMonkey? If so, that could possibly be
>>>>> the cause.

>>>> It's enabled for nosuchapp.exe, seamonkey1.exe, firefox2.exe &
>>>> pmshell.exe.

>>> Disable it. Especially for newer Mozilla apps which have their own
>>> anti-aliasing.

>> For which? Only one on that list has been opened in the past 6 months,
>> and it isn't any Mozilla.

> Try renaming ft2lib.dll (you'll need to unlock it).
> Your crashes in nspr4 seem to be in PR_MD_WAIT_CV so those sys3170's
> seems to be crashing while waiting for a thread.
> Would be interesting to see the trap with libc065.xqs which can be
> created by downloading the exceptq71-dev package (Hobbes) and running
> mzpxqs on the libc065 map file. All the libc functions in your trp file
> seem to be related to [de]allocating high memory with it being called by
> Freetype.

I'm not going to change anything else before the current session has had a 
chance to crash. :-p

> One guess is that you have a font installed that is stressing out
> freetype in a way that no-one else has experienced. Another guess is
> that you have a lot of fonts installed and something is overflowing as
> the font list is rebuilt over and over.

Maybe "no one else" because I'm the only one left with Smartsuite and its 
fonts installed, or the multimegabyte monotype sans and times new roman TTF 
files ? This is my list of what's installed: 
http://fm.no-ip.com/Tmp/psfontlist.txt

Maybe just removing those two big files is worth a shot all by itself? US 
English is all I need.

System font is Trebuchet 10pt.

Also I wonder if it's possible DPI could be playing any part. Devs tend to 
run at 96. I don't.
-- 
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

  Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/
0
Felix
10/19/2012 3:59:26 AM
Felix Miata wrote:
> On 2012-10-18 20:25 (GMT-0700) Dave Yeo composed:
>
>> Felix Miata wrote:
>
>>> On 2012-10-18 18:01 (GMT-0700) Dave Yeo composed:
>
>>>>>> That tells me libc065 is crashing due to some font code. Do you have
>>>>>> Innotek's FT2LIB enabled for SeaMonkey? If so, that could possibly be
>>>>>> the cause.
>
>>>>> It's enabled for nosuchapp.exe, seamonkey1.exe, firefox2.exe &
>>>>> pmshell.exe.
>
>>>> Disable it. Especially for newer Mozilla apps which have their own
>>>> anti-aliasing.
>
>>> For which? Only one on that list has been opened in the past 6 months,
>>> and it isn't any Mozilla.
>
>> Try renaming ft2lib.dll (you'll need to unlock it).
>> Your crashes in nspr4 seem to be in PR_MD_WAIT_CV so those sys3170's
>> seems to be crashing while waiting for a thread.
>> Would be interesting to see the trap with libc065.xqs which can be
>> created by downloading the exceptq71-dev package (Hobbes) and running
>> mzpxqs on the libc065 map file. All the libc functions in your trp file
>> seem to be related to [de]allocating high memory with it being called by
>> Freetype.
>
> I'm not going to change anything else before the current session has had
> a chance to crash. :-p

If you unlock and rename it, it won't take effect until you reboot (or 
restart the WPS) as it'll still be in memory.

>
>> One guess is that you have a font installed that is stressing out
>> freetype in a way that no-one else has experienced. Another guess is
>> that you have a lot of fonts installed and something is overflowing as
>> the font list is rebuilt over and over.
>
> Maybe "no one else" because I'm the only one left with Smartsuite and
> its fonts installed,

Seems to be truetype font related and smartsuite is all postscript fonts.

> or the multimegabyte monotype sans and times new
> roman TTF files ?

Those are both on my eCS 2.1 partition and my Warp partition has the 
other Times New Roman font that is even bigger.

> This is my list of what's installed:
> http://fm.no-ip.com/Tmp/psfontlist.txt

Doesn't seem too many fonts, I've got more I believe. There are quite a 
few I haven't heard of and possibly one of those is broken in some 
subtle way.

>
> Maybe just removing those two big files is worth a shot all by itself?
> US English is all I need.

I don't think those are the problem. Really I guess we need a program 
that can validate TTF fonts for not having errors.

>
> System font is Trebuchet 10pt.
>
> Also I wonder if it's possible DPI could be playing any part. Devs tend
> to run at 96. I don't.

I'm not knowledgeable about how the DPI is taken care off to comment 
though it is a good question
Dave
ps You could also try removing your FCCACHE.INI files from %HOME%, 
%TEMP% and perhaps the program directory.
0
Dave
10/19/2012 4:27:37 AM
Dave Yeo wrote:
> I don't think those are the problem. Really I guess we need a program
> that can validate TTF fonts for not having errors.

There's fontforge and TTX/Fonttools. Both would probably be simpler to 
install in Linux and mount your OS/2 partition or copy your fonts to it 
and test your fonts. Seems to be a few ways a bad font can allocate too 
much memory and with fontforge you can even rebuild them to remove 
errors. You'll have to read the documentation
Dave
0
Dave
10/19/2012 4:44:47 AM
On Thu, 18 Oct 2012 23:30:24 UTC, Paul Ratcliffe 
<abuse@orac12.clara34.co56.uk78> wrote:

> On Thu, 18 Oct 2012 10:38:51 -0500, Doug Bissett <dougb007!SPAM@telus.net>
> wrote:
> 
> >> > Actually, There is one more change that you should make: Add the line 
> >> > DLLBASING=OFF
> >> > near the top of your CONFIG.SYS.
> >> 
> >> Shouldn't that be "SET DLLBASING=OFF"
> >> 
> >> <runs away guffawing>
> > 
> > Showing your ignorance again Paul?
> 
> No, just teasing you unmercilessly. I guess it went over your head.
> "Whoosh" as they say.

I hope you were looking in the mirror when you typed that. "Whoosh" 
would describe it, as you say.

Posting nonsense such as you did can result in users being very 
confused. In the future, please use that lump of meat on top of your 
shoulders for something other than to hold your hat.

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

0
Doug
10/19/2012 4:53:45 AM
On 10/18/12 04:55 pm, Felix Miata wrote:

> I had no luck figuring out what zip it came from. I'm pretty sure it's
> 2.6b.
>
> Directory of F:\os2\dll
> 2-01-05 1:15p 421,348 0 a--- ft2lib.dll

Looks like 2.6b to me.
0
Steve
10/19/2012 5:56:14 AM
On Thu, 18 Oct 2012 23:53:45 -0500, Doug Bissett <dougb007!SPAM@telus.net>
wrote:

>> >> > Actually, There is one more change that you should make: Add the line 
>> >> > DLLBASING=OFF
>> >> > near the top of your CONFIG.SYS.
>> >> 
>> >> Shouldn't that be "SET DLLBASING=OFF"
>> >> 
>> >> <runs away guffawing>
>> > 
>> > Showing your ignorance again Paul?
>> 
>> No, just teasing you unmercilessly. I guess it went over your head.
>> "Whoosh" as they say.
>
> I hope you were looking in the mirror when you typed that. "Whoosh" 
> would describe it, as you say.

No, I was perfectly aware of what I was writing and what the correct
statements are and aren't.
The fact that you had to question me shows it had gone way over your
head. The "whoosh" is definitely with you - I thought about calling
air traffic control to warn them.

> Posting nonsense such as you did can result in users being very 
> confused.

Indeed. It has never stopped you though. Do you get it yet?
I expect not.
0
Paul
10/19/2012 9:25:00 PM
Silvan!!!

Excellent news indeed then...thank you so much! I am happy to test for you...LOL

Still, there are a pile of other QT apps that hold my interest, so I'll probably
dabble with this a little bit, there is always something there to learn. The 
difference now is that Firefox will get a lot more attention.

Oh, btw, the 0.10 version of PSI tends to lock-up (soft lock) my system once in 
a while, usually also tossing the CPU spike into the mix, so maybe a library 
issue???...I am guessing 0.15 is sufficiently different...any chance you might 
have come across anything that directly addresses this?

-Dariusz


On Thu, 18 Oct 2012 10:05:52 UTC, Silvan Scherrer <silvan.scherrer@aroa.ch> 
wrote:

> Dariusz,
> 
> just to let you know, i have a psi 0.15 build almost done. So don't 
> waste time on it :)
> 
> regards
> Silvan
> 
> Dariusz Piatkowski wrote:
> > Hi Dave!
> > 
> > 
> > On Sun, 14 Oct 2012 01:49:37 UTC, Dave Yeo <dave.r.yeo@gmail.com> wrote:
> > 
> > 
> >>>Why are the OS/2 levels so far behind? There are no dates on these
> >>>levels so there is no way to put a time frame around these newer levels.
> >>
> >>The OS/2 builds are so far behind due to lack of developers. I can build 
> >>newer versions but they crash...
> >>Dave
> > 
> > 
> > 
> > So how the heck do the rest of us get involved? I had previously asked this 
> > question, received some pointers...spent some time looking into the project and 
> > quite frankly, was completely lost!!!
> > 
> > The code complexity is one thing, but the overall OS/2 framework, what resources
> > such as compiler, libraries, tools to use is nothing but a major brick wall. Is 
> > there not a document somewhere which spells out, one by one, how a given OS/2 
> > machine needs to be set up? Is there not a downloadable environment that could 
> > be utilized which is already pre-configured?
> > 
> > In my case, I have my daily use machine (which is SMP configured and is very 
> > fast for just about everything I ask it to do). I also have my old hardware 
> > still kicking around with a complete OS/2 environment setup that could be used 
> > as a spare box to do work with. Effectively, that means as a developer (I'm an 
> > IS professional by trade and spent a few years wearing exactly those shoes) I 
> > have my build & test boxes readily available to me. 
> > 
> > Given the rather steep climb on the Firefox project I have now started looking 
> > at the QT framework in hopes of compiling the new version of PSI IM client. Will
> > it work? ....no idea...but you've got to try to know.
> > 
> > I would much rather devote my time to something like Firefox, but again, much 
> > help is needed to get started...


-- 

0
Dariusz
10/19/2012 9:30:03 PM
Dave Yeo wrote:
> Dave Yeo wrote:
>> Firefox 10.09esr has been uploaded to Netlabs.
>> This is another security fix update and all users of the 10 branch are
>> urged to update
>> Dave
>
> SeaMonkey also uploaded.
>

And Thunderbird
Dave

0
Dave
10/20/2012 1:03:38 AM
On Fri, 19 Oct 2012 21:25:00 UTC, Paul Ratcliffe 
<abuse@orac12.clara34.co56.uk78> wrote:

> No, I was perfectly aware of what I was writing and what the correct
> statements are and aren't.
> The fact that you had to question me shows it had gone way over your
> head. The "whoosh" is definitely with you - I thought about calling
> air traffic control to warn them.
 
This is off topic, and definitely not appropriate for this news group.
FYI, I got what you said. You did not read what I said. 

End of discussion...

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

0
Doug
10/20/2012 3:27:24 PM
New this month, fc250

Felix Miata wrote:
> On 2012-10-14 18:01 (GMT-0700) Dave Yeo composed:
> 
>> Felix Miata wrote:
> 
>>> After boot and opening the essentials (FC/2 & XFile via startup folder,
>>> 2 DOS apps manually), FC/2 says I have 2,074,263,552 of 2,145,906,688
>>> free. Once a Gecko (normally SM 2.x, as I typically go weeks or even
>>> months without opening any FF on eCS) have dropped free below
>>> 1,500,000,000, I can expect a it/them to die in short order.
> 
>> There's something wrong here. SeaMonkey shouldn't have problems when
>> only using 500MBs. My SeaMonkey is currently using 628MBs and usually
>> uses more. Of that most of the shared memory is in the high arena.
> 
> I really don't pay much attention to RAM. I just see what FC/2 says 
> occasionally, and have my suspicions whether it really has any idea 
> what's going on in upper RAM space. I've never seen it report as low as 
> 1,399,999,999 free, and infrequently seen it very far below 
> 1,500,000,000 before SM dies.
> 
> IIRC its author migrated to Linux at least a half decade ago, which may 
> mean he does little with it specific to OS/2, focusing more on keeping 
> it building on OS/2 while working the feature set based on personal use 
> on Linux and feedback from more Windows users than the others it's built 
> for.
> 
>> Perhaps the lack of programs that you're running is allowing SeaMonkey
>> to run in low memory instead of high memory. You could look with Theseus
>> or try to start something like Firefox first to allocate low memory.
>> There is an application that does this but I don't remember the name.
> 
> Right now on Linux I have SM 2.13.1, SM 2.14bX, FF 2.0.0.20, FF 3.6.28 & 
> FF 16.0.1 combined running well over 100 tabs, not including CZ in one 
> SM and mailnews in the other, in addition to KPDF, Konq, File Commander, 
> and several VC, Konsole & MC sessions. RAM used by basesystem, KDE and 
> apps is about half of 4G, with the rest about evenly split between free 
> and cache. Though I do have swap space on disk, I have it disabled. 
> Linux isn't inept at using a lot of RAM. Its apps in those uncommon 
> cases where crashing occurs, don't drive CPU to 100% or prevent access 
> to uncrashed apps. The WPS has some nice features either exclusive or 
> poorly shared by other desktops, but they've ceased to be worth the pain 
> of having it be a primary or exclusive desktop environment. Linux sure 
> isn't perfect, but it's easier, and less expensive, to live with. RAM 
> utilization is a big reason why. Geckos being noticeably faster and 
> non-crashing are other biggies. I keep using eCS now mostly because of 
> its bulletproof, speedy and easy SVGA text DOS.
> 
>> What's your virtualaddresslimit set to?
> 
> Current is 1024, but I don't remember seeing any impact compared to 2048 
> or 1536. This discussion does make me curious how behavior might change 
> if I pulled the pair of 1024 sticks and put back the original pair of 256s.
0
Bob
10/21/2012 8:46:27 PM
On 2012-10-19 00:44 (GMT-0400) Dave Yeo composed:

> Dave Yeo wrote:

>> I don't think those are the problem. Really I guess we need a program
>> that can validate TTF fonts for not having errors.

> There's fontforge and TTX/Fonttools. Both would probably be simpler to
> install in Linux and mount your OS/2 partition or copy your fonts to it
> and test your fonts. Seems to be a few ways a bad font can allocate too
> much memory and with fontforge you can even rebuild them to remove
> errors. You'll have to read the documentation

I installed both. Only Fontforge shows in KDE menu. Fonttools has no man page 
and has no executable named fonttools in the path, or any instructions what 
binary starts it.

Validation -> Validate in FontForge "Element" menu:
AHEM.TTF: pass
AndaleMo.TTF: Self Intersecting; multiple Missing Points at Extrema; locks 
up/cannot close, just kill -9 to exit
AriBlk.TTF: multiple Flipped References
CAPITALS.TTF: multiple Wrong Direction; multiple Missing Points at Extrema; 
multiple Self Intersecting
Charcoal.TTF: multiple Wrong Direction; multiple Missing Points at Extrema; 
multiple Self Intersecting
Chicago.TTF: multiple Missing Points at Extrema; multiple Self Intersecting
Code2001.TTF: massive number of Missing Points at Extrema
DejaVuSans-Bold.ttf: massive number of Missing Points at Extrema
DejaVuSans-BoldOblique.ttf: massive number of Missing Points at Extrema
DejaVuSans-ExtraLight.ttf: large number of Missing Points at Extrema
DejaVuSans-Oblique.ttf: massive number of Missing Points at Extrema
DejaVuSans.ttf: massive number of Missing Points at Extrema
DejaVuSans-Condensed-Bold.ttf: massive number of Missing Points at Extrema; 
multiple Wrong Direction; Self Intersecting
DejaVuSans-Condensed-BoldOblique.ttf: massive number of Missing Points at Extrema
DejaVuSans-Condensed-Oblique.ttf: massive number of Missing Points at Extrema
DejaVuSansMono-BoldOblique.ttf: (skipped validate) but as with all others 
opened to validate, simply opening the font opens a message window with the 
following:

Attempt to read script data beyond end of GSUB table
The glyph named mu is mapped to U+00B5.
   But its name indicates it should be mapped to U+03BC.
The glyph named Delta is mapped to U+2206.
   But its name indicates it should be mapped to U+0394.

What am I doing wrong to get so many errors?
-- 
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

  Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/
0
Felix
10/22/2012 11:11:28 PM
On 2012-10-18 16:33 (GMT-0400) Felix Miata composed:

> SM crashed at about 40 hours even though I never did anything in the browser
> window and did very little in the CZ window. Now I've booted with
> DLLBASING=OFF to try again.

SM lasted about 4 days before crashing this time. 
http://fm.no-ip.com/Tmp/005a_01.trp

For current boot I renamed ft2lib.dll to ft2libdll and in CONFIG.SYS:
@@ -45,8 +46,8 @@
  REM VIRTUALADDRESSLIMIT=2048
-REM VIRTUALADDRESSLIMIT=1536
-VIRTUALADDRESSLIMIT=1024
+VIRTUALADDRESSLIMIT=1536
+REM VIRTUALADDRESSLIMIT=1024
  EARLYMEMINIT=TRUE
-- 
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

  Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/
0
Felix
10/23/2012 1:12:40 AM
Felix Miata wrote:
> On 2012-10-19 00:44 (GMT-0400) Dave Yeo composed:
>
>> Dave Yeo wrote:
>
>>> I don't think those are the problem. Really I guess we need a program
>>> that can validate TTF fonts for not having errors.
>
>> There's fontforge and TTX/Fonttools. Both would probably be simpler to
>> install in Linux and mount your OS/2 partition or copy your fonts to it
>> and test your fonts. Seems to be a few ways a bad font can allocate too
>> much memory and with fontforge you can even rebuild them to remove
>> errors. You'll have to read the documentation
>
> I installed both. Only Fontforge shows in KDE menu. Fonttools has no man
> page and has no executable named fonttools in the path, or any
> instructions what binary starts it.

It's a Python extension so I'd guess that somewhere on your system are 
some scripts that use it. You'll have to examine the package or look at 
the package log somewhere in /var

>
> Validation -> Validate in FontForge "Element" menu:
> AHEM.TTF: pass
> AndaleMo.TTF: Self Intersecting; multiple Missing Points at Extrema;
> locks up/cannot close, just kill -9 to exit

For AndaleMo.TTF I get
The following table(s) in the font have been ignored by FontForge
   Ignoring 'DSIG' digital signature table
The glyph named macron is mapped to U+02C9.
But its name indicates it should be mapped to U+00AF.
Validation AndaleMono ...Failed
   Self Intersecting Glyph
   Missing Points at Extrema

no crash though. Possibly a different version of AndaleMono, It's dated 
05/18/2003 and 105468 bytes.

> AriBlk.TTF: multiple Flipped References

The following table(s) in the font have been ignored by FontForge
   Ignoring 'DSIG' digital signature table
   Ignoring 'LTSH' linear threshold table
   Ignoring 'hdmx' horizontal device metrics table
Glyph 2 is called ".notdef", a singularly inept choice of name (only glyph 0
  may be called .notdef)
FontForge will rename it.
The glyph named pi1 is mapped to U+F006.
But its name indicates it should be mapped to U+03D6.
The glyph named periodcentered is mapped to U+2219.
But its name indicates it should be mapped to U+00B7.
The glyph named macron is mapped to U+02C9.
But its name indicates it should be mapped to U+00AF.
The glyph named foursuperior is mapped to U+F003.
But its name indicates it should be mapped to U+2074.
The glyph named fivesuperior is mapped to U+F007.
But its name indicates it should be mapped to U+2075.
The glyph named sevensuperior is mapped to U+F008.
But its name indicates it should be mapped to U+2077.
The glyph named eightsuperior is mapped to U+F009.
But its name indicates it should be mapped to U+2078.
Validation Arial-Black ...Failed
   Self Intersecting Glyph
   Wrong Direction
   Flipped Reference

> CAPITALS.TTF: multiple Wrong Direction; multiple Missing Points at
> Extrema; multiple Self Intersecting
> Charcoal.TTF: multiple Wrong Direction; multiple Missing Points at
> Extrema; multiple Self Intersecting
> Chicago.TTF: multiple Missing Points at Extrema; multiple Self Intersecting
> Code2001.TTF: massive number of Missing Points at Extrema
> DejaVuSans-Bold.ttf: massive number of Missing Points at Extrema
> DejaVuSans-BoldOblique.ttf: massive number of Missing Points at Extrema
> DejaVuSans-ExtraLight.ttf: large number of Missing Points at Extrema
> DejaVuSans-Oblique.ttf: massive number of Missing Points at Extrema
> DejaVuSans.ttf: massive number of Missing Points at Extrema

Here with the DejaVu installed by eCS 2.1,
This font contains both a 'kern' table and a 'GPOS' table.
   The 'kern' table will only be read if there is no 'kern' feature in 
'GPOS'.
A point in GID 88 is outside the glyph bounding box
A point in GID 243 is outside the glyph bounding box
Use-my-metrics flag set on at least two components in glyph 685
A point in GID 689 is outside the glyph bounding box
A point in GID 690 is outside the glyph bounding box
A point in GID 691 is outside the glyph bounding box
A point in GID 696 is outside the glyph bounding box
A point in GID 697 is outside the glyph bounding box
A point in GID 701 is outside the glyph bounding box
A point in GID 2894 is outside the glyph bounding box
A point in GID 2895 is outside the glyph bounding box
A point in GID 4720 is outside the glyph bounding box
A point in GID 5439 is outside the glyph bounding box
The glyph named mu is mapped to U+00B5.
But its name indicates it should be mapped to U+03BC.
The glyph named Delta is mapped to U+2206.
But its name indicates it should be mapped to U+0394.

Killed by SIGFPE
pid=0x5fd1 ppid=0x004f tid=0x0001 slot=0x00bb pri=0x0200 mc=0x0001
I:\USR\SRC\FONTFORGE-20120731-B\FONTFORGE\FONTFORGE.EXE
FONTFORG 0:0002f374
cs:eip=005b:0003f374      ss:esp=0053:0058f0e0      ebp=0058f138
  ds=0053      es=0053      fs=150b      gs=0000     efl=00010206
eax=00cb4120 ebx=0136aae0 ecx=00cb22d0 edx=0136ab40 edi=0136aba0 
esi=00000001
Process dumping was disabled, use DUMPPROC / PROCDUMP to enable it.

lots of other fonts are causing a similar crash which I'll try to track 
down later.

> DejaVuSans-Condensed-Bold.ttf: massive number of Missing Points at
> Extrema; multiple Wrong Direction; Self Intersecting
> DejaVuSans-Condensed-BoldOblique.ttf: massive number of Missing Points
> at Extrema
> DejaVuSans-Condensed-Oblique.ttf: massive number of Missing Points at
> Extrema
> DejaVuSansMono-BoldOblique.ttf: (skipped validate) but as with all
> others opened to validate, simply opening the font opens a message
> window with the following:
>
> Attempt to read script data beyond end of GSUB table
> The glyph named mu is mapped to U+00B5.
> But its name indicates it should be mapped to U+03BC.
> The glyph named Delta is mapped to U+2206.
> But its name indicates it should be mapped to U+0394.
>
> What am I doing wrong to get so many errors?

I really don't know enough about it but it seems fontforge really does 
consider them errors. There is a lot of documentation which never the 
less seems incomplete.
I ran fontlint for the above output.
Dave
0
Dave
10/23/2012 5:42:02 AM
Felix Miata wrote:
> On 2012-10-18 16:33 (GMT-0400) Felix Miata composed:
>
>> SM crashed at about 40 hours even though I never did anything in the
>> browser
>> window and did very little in the CZ window. Now I've booted with
>> DLLBASING=OFF to try again.
>
> SM lasted about 4 days before crashing this time.
> http://fm.no-ip.com/Tmp/005a_01.trp

Much the same as the other crash. I'd have to restart SeaMonkey before 4 
days due to excessive swapping, I have a lot of tabs open :)

>
> For current boot I renamed ft2lib.dll to ft2libdll and in CONFIG.SYS:
> @@ -45,8 +46,8 @@
> REM VIRTUALADDRESSLIMIT=2048
> -REM VIRTUALADDRESSLIMIT=1536
> -VIRTUALADDRESSLIMIT=1024
> +VIRTUALADDRESSLIMIT=1536
> +REM VIRTUALADDRESSLIMIT=1024
> EARLYMEMINIT=TRUE

Dave
0
Dave
10/23/2012 5:47:41 AM
Op 13-10-12 04:32, Dave Yeo schreef:
> Firefox 10.09esr has been uploaded to Netlabs.
> This is another security fix update and all users of the 10 branch are
> urged to update
> Dave
Thanks Dave, but I found a bug. I print my invoices from XS4ALL (my port 
to www) with FF because they are online. The first is alright, its a pdf 
as it should be. The second and up are garbage. Don't know what's going 
wrong. I had to go all the way down to version 6.02 which does the job 
right. Sorry for late information, I only print it once half a year. I 
don't have versions in between, deleted it because it takes space and 
maintenance on the hard drive.
Joop

0
Joop
10/26/2012 5:04:39 PM
Joop Nijenhuis wrote:
> Op 13-10-12 04:32, Dave Yeo schreef:
>> Firefox 10.09esr has been uploaded to Netlabs.
>> This is another security fix update and all users of the 10 branch are
>> urged to update
>> Dave
> Thanks Dave, but I found a bug. I print my invoices from XS4ALL (my port
> to www) with FF because they are online. The first is alright, its a pdf
> as it should be. The second and up are garbage. Don't know what's going
> wrong. I had to go all the way down to version 6.02 which does the job
> right. Sorry for late information, I only print it once half a year. I
> don't have versions in between, deleted it because it takes space and
> maintenance on the hard drive.
> Joop
>

Yes, it's a known problem.
Dave
0
Dave
10/26/2012 10:44:21 PM
On 2012-10-22 21:12 (GMT-0400) Felix Miata composed:

> For current boot I renamed ft2lib.dll to ft2libdll and in CONFIG.SYS:
> @@ -45,8 +46,8 @@
>    REM VIRTUALADDRESSLIMIT=2048
> -REM VIRTUALADDRESSLIMIT=1536
> -VIRTUALADDRESSLIMIT=1024
> +VIRTUALADDRESSLIMIT=1536
> +REM VIRTUALADDRESSLIMIT=1024
>    EARLYMEMINIT=TRUE

10 days up. Free RAM down to 1,493,438,434. But, SM is mostly idling. CZ is 
using most SM cycles. Most of the time FS SVGA DOS has focus, and likely 
using no more than about 12M RAM.
-- 
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

  Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/
0
Felix
11/2/2012 4:14:38 AM
On 2012-11-02 00:14 (GMT-0500) Felix Miata composed:

> On 2012-10-22 21:12 (GMT-0400) Felix Miata composed:

>> For current boot I renamed ft2lib.dll to ft2libdll and in CONFIG.SYS:
>> @@ -45,8 +46,8 @@
>>    REM VIRTUALADDRESSLIMIT=2048
>> -REM VIRTUALADDRESSLIMIT=1536
>> -VIRTUALADDRESSLIMIT=1024
>> +VIRTUALADDRESSLIMIT=1536
>> +REM VIRTUALADDRESSLIMIT=1024
>>    EARLYMEMINIT=TRUE

> 10 days up. Free RAM down to 1,493,438,434. But, SM is mostly idling. CZ is
> using most SM cycles. Most of the time FS SVGA DOS has focus, and likely
> using no more than about 12M RAM.

13.7 days up. Free RAM is 1,393,860,608, the lowest I've ever seen it.
-- 
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

  Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/
0
Felix
11/5/2012 4:50:11 PM
On Mon, 5 Nov 2012 16:50:11 UTC, Felix Miata 
<UgaddaBkidding.due2UCE@dev.nul> wrote:

> On 2012-11-02 00:14 (GMT-0500) Felix Miata composed:
> 
> > On 2012-10-22 21:12 (GMT-0400) Felix Miata composed:
> 
> >> For current boot I renamed ft2lib.dll to ft2libdll and in CONFIG.SYS:
> >> @@ -45,8 +46,8 @@
> >>    REM VIRTUALADDRESSLIMIT=2048
> >> -REM VIRTUALADDRESSLIMIT=1536
> >> -VIRTUALADDRESSLIMIT=1024
> >> +VIRTUALADDRESSLIMIT=1536
> >> +REM VIRTUALADDRESSLIMIT=1024
> >>    EARLYMEMINIT=TRUE
> 
> > 10 days up. Free RAM down to 1,493,438,434. But, SM is mostly idling. CZ is
> > using most SM cycles. Most of the time FS SVGA DOS has focus, and likely
> > using no more than about 12M RAM.
> 
> 13.7 days up. Free RAM is 1,393,860,608, the lowest I've ever seen it.

I don't think that "free RAM" has anything to do with your problem. It
is more likely "free SHARED RAM" that is causing the problem. With the
changes that you made, SHARED RAM should be used more efficiently. Of 
course, there may be a limit to that improvement, if there is 
something that is using it up, without releasing it again.

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

0
Doug
11/5/2012 6:40:12 PM
On 2012-11-05 12:40 (GMT-0600) Doug Bissett composed:

> Felix Miata wrote:

>> > 10 days up. Free RAM down to 1,493,438,434. But, SM is mostly idling. CZ is
>> > using most SM cycles. Most of the time FS SVGA DOS has focus, and likely
>> > using no more than about 12M RAM.

>> 13.7 days up. Free RAM is 1,393,860,608, the lowest I've ever seen it.

> I don't think that "free RAM" has anything to do with your problem. It
> is more likely "free SHARED RAM" that is causing the problem. With the
> changes that you made, SHARED RAM should be used more efficiently. Of
> course, there may be a limit to that improvement, if there is
> something that is using it up, without releasing it again.

Whether free or shared or how much of either isn't why I posted. I noted 
previously that once the number dropped below 1,500,000,000, it would only be 
a short time until SM crashed. IOW, one of those two changes I made to 
CONFIG.SYS changed or eliminated the crash threshhold. ISTR changing 
VIRTUALADDRESSLIMIT in the past had no effect, so I have to think eliminating 
PMSHELL's use of ft2lib.dll would be the responsible change.
-- 
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

  Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/
0
Felix
11/6/2012 12:16:02 AM
On 11/5/2012 4:16 PM, Felix Miata wrote:

> eliminating PMSHELL's use of ft2lib.dll would be the responsible
> change.

I'm sure that's true - your crashes were in font code.

0
Steve
11/6/2012 1:03:54 AM
On 2012-11-05 17:03 (GMT-0800) Steve Wendt composed:

> Felix Miata wrote:

>> eliminating PMSHELL's use of ft2lib.dll would be the responsible
>> change.

> I'm sure that's true - your crashes were in font code.

That was the upthread consensus as I read it, but why if it was supposed to 
be limited to PMSHELL would it cause SM to crash? I know PMSHELL can't be 
entirely divorced from PM apps. But, it seems to me Gecko & PM ought to be 
able to play nicer together. NAICT, PM itself is only using one font family 
in apps' UIs. Isn't Gecko doing its own font rendering within the viewport? 
Maybe the overall Gecko slowness I see compared to Linux & M$ is because both 
are doing something with available font files that only one or the other 
should be doing, and this presents the opportunity to crash with blame on ft2lib?
-- 
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

  Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/
0
Felix
11/6/2012 1:57:45 AM
On 11/05/12 05:57 pm, Felix Miata wrote:
> On 2012-11-05 17:03 (GMT-0800) Steve Wendt composed:
>
>> Felix Miata wrote:
>
>>> eliminating PMSHELL's use of ft2lib.dll would be the responsible
>>> change.
>
>> I'm sure that's true - your crashes were in font code.
>
> That was the upthread consensus as I read it, but why if it was supposed
> to be limited to PMSHELL would it cause SM to crash? I know PMSHELL
> can't be entirely divorced from PM apps. But, it seems to me Gecko & PM
> ought to be able to play nicer together. NAICT, PM itself is only using
> one font family in apps' UIs. Isn't Gecko doing its own font rendering
> within the viewport? Maybe the overall Gecko slowness I see compared to
> Linux & M$ is because both are doing something with available font files
> that only one or the other should be doing, and this presents the
> opportunity to crash with blame on ft2lib?

FT2LIB was never really finished and IIRC Innotek advised against using 
it for the PMSHELL itself.
Dave
0
Dave
11/6/2012 3:37:24 AM
On 2012-11-05 11:50 (GMT-0500) Felix Miata composed:

> On 2012-11-02 00:14 (GMT-0500) Felix Miata composed:

>> On 2012-10-22 21:12 (GMT-0400) Felix Miata composed:

>>> For current boot I renamed ft2lib.dll to ft2libdll and in CONFIG.SYS:
>>> @@ -45,8 +46,8 @@
>>>    REM VIRTUALADDRESSLIMIT=2048
>>> -REM VIRTUALADDRESSLIMIT=1536
>>> -VIRTUALADDRESSLIMIT=1024
>>> +VIRTUALADDRESSLIMIT=1536
>>> +REM VIRTUALADDRESSLIMIT=1024
>>>    EARLYMEMINIT=TRUE

>> 10 days up. Free RAM down to 1,493,438,434. But, SM is mostly idling. CZ is
>> using most SM cycles. Most of the time FS SVGA DOS has focus, and likely
>> using no more than about 12M RAM.

> 13.7 days up. Free RAM is 1,393,860,608, the lowest I've ever seen it.

The crashing may have stopped, but it's obviously not happy. I actually tried 
to open new tabs and pages in the browser beyond the 12 that have been 
auto-opening in recent weeks and left alone, and just about any activity in a 
new tab pegs the CPU for quite a while, as does closing those new ones.

It needs rebooting anyway for the clock change. Not means filesystem async 
between Peer & Linux on the LAN.
-- 
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

  Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/
0
Felix
11/6/2012 4:26:36 AM
On Tue, 6 Nov 2012 00:16:02 UTC, Felix Miata 
<UgaddaBkidding.due2UCE@dev.nul> wrote:

> On 2012-11-05 12:40 (GMT-0600) Doug Bissett composed:
> 
> > Felix Miata wrote:
> 
> >> > 10 days up. Free RAM down to 1,493,438,434. But, SM is mostly idling. CZ is
> >> > using most SM cycles. Most of the time FS SVGA DOS has focus, and likely
> >> > using no more than about 12M RAM.
> 
> >> 13.7 days up. Free RAM is 1,393,860,608, the lowest I've ever seen it.
> 
> > I don't think that "free RAM" has anything to do with your problem. It
> > is more likely "free SHARED RAM" that is causing the problem. With the
> > changes that you made, SHARED RAM should be used more efficiently. Of
> > course, there may be a limit to that improvement, if there is
> > something that is using it up, without releasing it again.
> 
> Whether free or shared or how much of either isn't why I posted. I noted 
> previously that once the number dropped below 1,500,000,000, it would only be 
> a short time until SM crashed. IOW, one of those two changes I made to 
> CONFIG.SYS changed or eliminated the crash threshhold. ISTR changing 
> VIRTUALADDRESSLIMIT in the past had no effect, so I have to think eliminating 
> PMSHELL's use of ft2lib.dll would be the responsible change.
Changing the VIRTUALADDRESSLIMIT may or may not help depending on the 
circumstances.
I have just been doing some testing with it and found the following:
Using VPC as my test application:
with VIRTUALADDRESSLIMIT (VAL) set to 1536 I could give VPC 825M of 
memory before it started shrinking the size of the shared memory area.
 It shrunk the Shared Memory area about 25M for each 50M above 825M up
to nearly 200M by the time I reached 1024M.
Changing the VAL to 1792 I was then able to set the memory on VPC to 
1024M without shrinking the Shared Memory space.
From what I have been able to glean, the entire amount given to VAL is
not available to applications and will begin growing into lower 
memory, thus shrinking the free shared memory pool (though not being 
shared memory itself).  By increasing the size of the VAL I was able 
to load the entire 1024M into high memory and thus not use the lower 
memory area.
This would hit someone sooner with VAL set (or defaulted) to 1024M 
where Seamonkey/Firefox would have to use something over 500M before 
it would start growing into the lower memory area but over time that 
could be an issue.  I am guessing on the 500M mark as I have not 
tested but am making a guess based on the 825M with a VAL of 1536M.  
It could be somewhat lower or higher in practice but the idea being 
that the VAL has to be considerably larger than the amount to place 
there (at least what I consider considerably).
For some more concrete information:
http://www.os2voice.org/VNL/past_issues/VNL0708H/feature_3.html
Andy
-- 

0
Andy
11/7/2012 4:33:29 PM
On 2012-11-05 23:26 (GMT-0500) Felix Miata composed:

> On 2012-11-05 11:50 (GMT-0500) Felix Miata composed:

>> On 2012-11-02 00:14 (GMT-0500) Felix Miata composed:

>>> On 2012-10-22 21:12 (GMT-0400) Felix Miata composed:

>>>> For current boot I renamed ft2lib.dll to ft2libdll and in CONFIG.SYS:
>>>> @@ -45,8 +46,8 @@
>>>>    REM VIRTUALADDRESSLIMIT=2048
>>>> -REM VIRTUALADDRESSLIMIT=1536
>>>> -VIRTUALADDRESSLIMIT=1024
>>>> +VIRTUALADDRESSLIMIT=1536
>>>> +REM VIRTUALADDRESSLIMIT=1024
>>>>    EARLYMEMINIT=TRUE

>>> 10 days up. Free RAM down to 1,493,438,434. But, SM is mostly idling. CZ is
>>> using most SM cycles. Most of the time FS SVGA DOS has focus, and likely
>>> using no more than about 12M RAM.

>> 13.7 days up. Free RAM is 1,393,860,608, the lowest I've ever seen it.

> The crashing may have stopped, but it's obviously not happy. I actually tried
> to open new tabs and pages in the browser beyond the 12 that have been
> auto-opening in recent weeks and left alone, and just about any activity in a
> new tab pegs the CPU for quite a while, as does closing those new ones.

> It needs rebooting anyway for the clock change. Not means filesystem async
> between Peer & Linux on the LAN.

Two crashes less than 48 hours apart, both without doing anything at the 
time, and without having done more than type a few lines in CZ since opening. 
Fullscreen DOS had focus each time. :-(

http://fm.no-ip.com/Tmp/006c_01.trp.txt
http://fm.no-ip.com/Tmp/007c_02.trp.txt
-- 
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

  Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/
0
Felix
11/16/2012 10:12:52 PM
Felix Miata wrote:
> On 2012-11-05 23:26 (GMT-0500) Felix Miata composed:
>
>> On 2012-11-05 11:50 (GMT-0500) Felix Miata composed:
>
>>> On 2012-11-02 00:14 (GMT-0500) Felix Miata composed:
>
>>>> On 2012-10-22 21:12 (GMT-0400) Felix Miata composed:
>
>>>>> For current boot I renamed ft2lib.dll to ft2libdll and in CONFIG.SYS:
>>>>> @@ -45,8 +46,8 @@
>>>>> REM VIRTUALADDRESSLIMIT=2048
>>>>> -REM VIRTUALADDRESSLIMIT=1536
>>>>> -VIRTUALADDRESSLIMIT=1024
>>>>> +VIRTUALADDRESSLIMIT=1536
>>>>> +REM VIRTUALADDRESSLIMIT=1024
>>>>> EARLYMEMINIT=TRUE
>
>>>> 10 days up. Free RAM down to 1,493,438,434. But, SM is mostly
>>>> idling. CZ is
>>>> using most SM cycles. Most of the time FS SVGA DOS has focus, and
>>>> likely
>>>> using no more than about 12M RAM.
>
>>> 13.7 days up. Free RAM is 1,393,860,608, the lowest I've ever seen it.
>
>> The crashing may have stopped, but it's obviously not happy. I
>> actually tried
>> to open new tabs and pages in the browser beyond the 12 that have been
>> auto-opening in recent weeks and left alone, and just about any
>> activity in a
>> new tab pegs the CPU for quite a while, as does closing those new ones.
>
>> It needs rebooting anyway for the clock change. Not means filesystem
>> async
>> between Peer & Linux on the LAN.
>
> Two crashes less than 48 hours apart, both without doing anything at the
> time, and without having done more than type a few lines in CZ since
> opening. Fullscreen DOS had focus each time. :-(
>
> http://fm.no-ip.com/Tmp/006c_01.trp.txt
> http://fm.no-ip.com/Tmp/007c_02.trp.txt

Interesting that the second one was a crash in exceptq. First one is 
once again in the font code
Dave
0
Dave
11/17/2012 4:27:00 AM
On Fri, 16 Nov 2012 22:12:52 UTC, Felix Miata 
<UgaddaBkidding.due2UCE@dev.nul> wrote:

Hi Felix,

> Two crashes less than 48 hours apart, both without doing anything at the 
> time, and without having done more than type a few lines in CZ since opening. 
> Fullscreen DOS had focus each time. :-(

Hard to say if this is relevant.  The thing is that the browsers are 
always doing something, even when the the browser windows do not have 
focus.

FWIW, 006c_01.trp implies heap corruption because

 Filename: F:\EMX\DLL\LIBC065.DLL
 Address:  005B:1DF0A4C7 (0001:0000A4C7)

decodes to

 32 Bit Symbol <_um_lump_unlink_bucket> Address 1:a498
 32 Bit Symbol <_um_lump_unlink_heap> Address 1:a4cc

I recommend you install the libc065.xqs available at

  http://home.earthlink.net/~steve53/betas/

This way exceptq can do the symbol lookups.

I'm not sure what's going on with 007c_02.trp.  Given the really odd 
exceptq ouput I have to suspect memory corruption of some sort.

You have xul.xqs installed, so the exception address

 Address:  005B:178AB083 (0001:012BB083)

should have decoded to

   0001:012BB7E0  nsCycleCollector::Collect
   0001:012BBA20  nsCycleCollector_collect

This is one of those background activities that I mentioned.

Steven


-- 
---------------------------------------------------------------------
Steven Levine <steve53@earthlink.bogus.net>
eCS/Warp/DIY etc. www.scoug.com www.ecomstation.com
---------------------------------------------------------------------
0
Steven
11/17/2012 4:09:40 PM
On Sat, 17 Nov 2012 04:27:00 UTC, Dave Yeo <dave.r.yeo@gmail.com> 
wrote:

Hi Dave,

> Interesting that the second one was a crash in exceptq. First one is 
> once again in the font code

I would not try to read anything into the second exception report in 
007c_02.trp.  Something went terribly wrong with exceptq.

The report that the exception is in nsCycleCollector::Collect is 
probably valid.  The rest, not so much.

Steven


-- 
---------------------------------------------------------------------
Steven Levine <steve53@earthlink.bogus.net>
eCS/Warp/DIY etc. www.scoug.com www.ecomstation.com
---------------------------------------------------------------------
0
Steven
11/17/2012 4:15:07 PM
On 2012-11-17 10:09 (GMT-0600) Steven Levine composed:

> Felix Miata wrote:

>> Two crashes less than 48 hours apart, both without doing anything at the
>> time, and without having done more than type a few lines in CZ since opening.
>> Fullscreen DOS had focus each time. :-(

> Hard to say if this is relevant.  The thing is that the browsers are
> always doing something, even when the the browser windows do not have
> focus.

Likely mine does little, with noscript by default disallowing all scripts. 
Most of what it does and requires has to be in CZ's inefficient <table> 
output. CZ is a pig, but otherwise very convenient.

> I recommend you install the libc065.xqs available at

>    http://home.earthlink.net/~steve53/betas/

Where does it go? App dir?? DLL dir???
-- 
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

  Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/
0
Felix
11/17/2012 5:27:33 PM
Felix Miata wrote:
>> I recommend you install the libc065.xqs available at
>
>> http://home.earthlink.net/~steve53/betas/
>
> Where does it go? App dir?? DLL dir???

Same place as libc065.dll is installed
Dave
0
Dave
11/17/2012 6:23:20 PM
On Sat, 17 Nov 2012 17:27:33 UTC, Felix Miata 
<UgaddaBkidding.due2UCE@dev.nul> wrote:

Hi,

> >    http://home.earthlink.net/~steve53/betas/
> 
> Where does it go? App dir?? DLL dir???

To add a bit to Dave's reply, here's a paraphrase of what is covered 
in the exceptq user docs.  As Dave stated, the xqs files must be in 
the same directory as the excutables.

Exceptq can use either sym or xqs files or HLL debug data.  The HLL 
debug data be attached to the excutables or in separate dbg files.  
For the Mozilla apps, xqs files are preferred.  HLL debug data is 
actually better, but this would make the distribution even bulkier 
than it already is.  The benefit of HLL debug data is the exceptq 
reports will conain line number detail.

It might be worthwhile to distribute the dbg files as a separate zip 
file, but generating the dbg files would require changes to the build 
process.

Steven

-- 
---------------------------------------------------------------------
Steven Levine <steve53@earthlink.bogus.net>
eCS/Warp/DIY etc. www.scoug.com www.ecomstation.com
---------------------------------------------------------------------
0
Steven
11/18/2012 7:18:49 AM
On 2012-11-18 01:18 (GMT-0600) Steven Levine composed:

> the xqs files must be in the same directory as the excutables.

Which executables? This sounds like the DLL DIR is the wrong place.

> Exceptq can use either sym or xqs files or HLL debug data.  The HLL
> debug data be attached to the excutables or in separate dbg files.
> For the Mozilla apps, xqs files are preferred.  HLL debug data is
> actually better, but this would make the distribution even bulkier
> than it already is.  The benefit of HLL debug data is the exceptq
> reports will conain line number detail.

I remember nothing about the Exceptq installation process. All I know is 
where to find the logs from SM crashes, and where I put non-system DLLs given 
any choice of location.
-- 
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

  Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/
0
Felix
11/18/2012 7:28:01 AM
On 11/17/12 11:18 pm, Steven Levine wrote:
> Exceptq can use either sym or xqs files or HLL debug data.  The HLL
> debug data be attached to the excutables or in separate dbg files.
> For the Mozilla apps, xqs files are preferred.  HLL debug data is
> actually better, but this would make the distribution even bulkier
> than it already is.  The benefit of HLL debug data is the exceptq
> reports will conain line number detail.
>
> It might be worthwhile to distribute the dbg files as a separate zip
> file, but generating the dbg files would require changes to the build
> process.

Actually debug builds fail. Usually with rc.exe complaining about too 
many page entries and using wrc, a crash on startup. This goes back to 
when the build process used static libs where emxomfar would fail due to 
too many page entries. Seems we've run into the limit of our object 
format, only 64 kbs of page entries.
How does attaching the hll dbg data to separate files work?
Dave

0
Dave
11/18/2012 8:39:00 AM
On Sun, 18 Nov 2012 07:28:01 UTC, Felix Miata 
<UgaddaBkidding.due2UCE@dev.nul> wrote:

Hi Felix,

> > the xqs files must be in the same directory as the excutables.
> 
> Which executables? This sounds like the DLL DIR is the wrong place.

DLLs are executables.  If licbo65.dll is in the \ecs\dll directory, 
that's where the xul.xqs would go.

Steven


-- 
---------------------------------------------------------------------
Steven Levine <steve53@earthlink.bogus.net>
eCS/Warp/DIY etc. www.scoug.com www.ecomstation.com
---------------------------------------------------------------------
0
Steven
11/18/2012 6:43:10 PM
On Sun, 18 Nov 2012 08:39:00 UTC, Dave Yeo <dave.r.yeo@gmail.com> 
wrote:

Hi,
 
> Actually debug builds fail. Usually with rc.exe complaining about too 
> many page entries and using wrc, a crash on startup.

We may be talking about different debug builds.  What I am talking 
about are builds done with the gcc -g option, not those built with a 
-dDEBUG macro that enabled additional debug code in the excutables.

If you mean the former, rc.exe might be showing it's age.  Wrc can 
probably be fixed.  If you can generate a process dump of the failure,
I will take a look at it.  I've been known to correct OpenWatcom 
defects now and then.

>This goes back to 
> when the build process used static libs where emxomfar would fail due to 
> too many page entries. Seems we've run into the limit of our object 
> format, only 64 kbs of page entries.

The 65K page limit should not affect debug data.  HLL debug data is 
appended the the executable 

> How does attaching the hll dbg data to separate files work?

Do you mean splitting the debug data to separate files.  Exceptq 
supports dbg files.   I'm pretty sure OpenWatcom's wstrip can handle 
the HLL format.  The legacy exceptq includes a copydbg utility that 
can create the dbg file, but does not modify the executable.

Steven


-- 
---------------------------------------------------------------------
Steven Levine <steve53@earthlink.bogus.net>
eCS/Warp/DIY etc. www.scoug.com www.ecomstation.com
---------------------------------------------------------------------
0
Steven
11/18/2012 6:59:42 PM
On 11/18/12 10:59 am, Steven Levine wrote:
> On Sun, 18 Nov 2012 08:39:00 UTC, Dave Yeo<dave.r.yeo@gmail.com>
> wrote:
>
> Hi,
>
>> Actually debug builds fail. Usually with rc.exe complaining about too
>> many page entries and using wrc, a crash on startup.
>
> We may be talking about different debug builds.  What I am talking
> about are builds done with the gcc -g option, not those built with a
> -dDEBUG macro that enabled additional debug code in the excutables.

I'm talking about the default, which is now to include debug symbols, 
even with --disable-debug. For quite a while we also need 
--disable-debug-symbols for the build to succeed.
Doing a test just now, -g is added to the compile line but now linking 
has a -s added and starting the binary in a debugger gives nothing but 
assembly.
Does wlink need something like -g?

Dave
0
Dave
11/18/2012 11:17:35 PM
On 2012-11-17 10:09 (GMT-0600) Steven Levine composed:

> I recommend you install the libc065.xqs available at

>    http://home.earthlink.net/~steve53/betas/

> This way exceptq can do the symbol lookups.

First "crash" since installing libc065.xqs produced only black where windows 
belong on return from SVGA fullscreen DOS, "infinitely" pegged CPU, no *.TRP, 
only speaker beep from clicking on shutdown icon, and CAD only recourse to 
get system control back.
-- 
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

  Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/
0
Felix
11/19/2012 1:58:56 AM
On 11/18/12 03:17 pm, Dave Yeo wrote:
> On 11/18/12 10:59 am, Steven Levine wrote:
>> On Sun, 18 Nov 2012 08:39:00 UTC, Dave Yeo<dave.r.yeo@gmail.com>
>> wrote:
>>
>> Hi,
>>
>>> Actually debug builds fail. Usually with rc.exe complaining about too
>>> many page entries and using wrc, a crash on startup.
>>
>> We may be talking about different debug builds. What I am talking
>> about are builds done with the gcc -g option, not those built with a
>> -dDEBUG macro that enabled additional debug code in the excutables.
>
> I'm talking about the default, which is now to include debug symbols,
> even with --disable-debug. For quite a while we also need
> --disable-debug-symbols for the build to succeed.
> Doing a test just now, -g is added to the compile line but now linking
> has a -s added and starting the binary in a debugger gives nothing but
> assembly.

OK, I didn't disable optimizations. Now the build dies with
Compile ending.
RC is reading the binary resource file 
G:\cc-release-10\mozilla\obj-fb.dbg\toolkit\library\xulrunos2.res.


RC :Error 2016:The page table has too many entries.
RC encountered an error while binding resources to executable file %s.

RC :Error 1009:RC detected errors during compilation.
make.exe[5]: *** [xul.dll] Error 1

Using wrc the compile finishes but launching Firefox causes,
11-18-2012  18:19:14  SYS3175  PID e6a6  TID 0001  Slot 00e4
G:\CC-RELEASE-10\MOZILLA\OBJ-FB.DBG\DIST\BIN\FIREFOX.EXE
c0000005
00000000
P1=0015eeb0  P2=1ed1acf2  P3=20030000  P4=f0004538
EAX=00000001  EBX=00000000  ECX=00000000  EDX=00000000
ESI=00000000  EDI=00000000
DS=0053  DSACC=f0f3  DSLIM=ffffffff
ES=0053  ESACC=f0f3  ESLIM=ffffffff
FS=150b  FSACC=00f3  FSLIM=00000030
GS=0000  GSACC=****  GSLIM=********
CS:EIP=005b:0d970002  CSACC=f0df  CSLIM=ffffffff
SS:ESP=0053:0012fe88  SSACC=f0f3  SSLIM=ffffffff
EBP=00000000  FLG=00010202

Launching Firefox in idbug, the source is displayed but when run is 
clicked I get a popup, the following source cannot be found: DLL0.S. 
Pressing cancel ends up with an exception (XCPT_ACCESS_VIOLATION ( 
Unhandled )) and an assembly listing.
Letting the exception handler run, it dies at an INT 3 in libc065.dll
Single stepping, it seems to die very early while trying to figure out 
the program path and preload xul.dll

Dave
0
Dave
11/19/2012 3:02:03 AM
On Sun, 18 Nov 2012 23:17:35 UTC, Dave Yeo <dave.r.yeo@gmail.com> 
wrote:

Hi,

> Doing a test just now, -g is added to the compile line but now linking 
> has a -s added and starting the binary in a debugger gives nothing but 
> assembly.
> Does wlink need something like -g?

Yes and the -s needs to go away since that is probably part of what is
stripping the debug data.  I'm not 100% sure on the -s statement.  I'd
have to look at the emxomfld code to see how it passes the -s through 
to wlink.

Steven


-- 
---------------------------------------------------------------------
Steven Levine <steve53@earthlink.bogus.net>
eCS/Warp/DIY etc. www.scoug.com www.ecomstation.com
---------------------------------------------------------------------
0
Steven
11/19/2012 6:50:45 AM
On Mon, 19 Nov 2012 03:02:03 UTC, Dave Yeo <dave.r.yeo@gmail.com> 
wrote:

Hi Dave,


> RC :Error 2016:The page table has too many entries.
> RC encountered an error while binding resources to executable file %s.

OK.

> Using wrc the compile finishes but launching Firefox causes,
> 11-18-2012  18:19:14  SYS3175  PID e6a6  TID 0001  Slot 00e4
> G:\CC-RELEASE-10\MOZILLA\OBJ-FB.DBG\DIST\BIN\FIREFOX.EXE
> c0000005
> 00000000
> P1=0015eeb0  P2=1ed1acf2  P3=20030000  P4=f0004538
> EAX=00000001  EBX=00000000  ECX=00000000  EDX=00000000
> ESI=00000000  EDI=00000000
> DS=0053  DSACC=f0f3  DSLIM=ffffffff
> ES=0053  ESACC=f0f3  ESLIM=ffffffff
> FS=150b  FSACC=00f3  FSLIM=00000030
> GS=0000  GSACC=****  GSLIM=********
> CS:EIP=005b:0d970002  CSACC=f0df  CSLIM=ffffffff
> SS:ESP=0053:0012fe88  SSACC=f0f3  SSLIM=ffffffff
> EBP=00000000  FLG=00010202
> 
> Launching Firefox in idbug, the source is displayed but when run is 
> clicked I get a popup, the following source cannot be found: DLL0.S. 

Dll.0.S is the runtime startup code for the DLL.  The source is part 
of gcc.  If you want to see the source code in idebug, you should be 
able to grab a copy from Paul's git repo.  However, you probably don't
need it for this issue.

> Pressing cancel ends up with an exception (XCPT_ACCESS_VIOLATION ( 
> Unhandled )) and an assembly listing.

The assembly listing is normal is there's no HLL debug data available.

> Letting the exception handler run, it dies at an INT 3 in libc065.dll

This is normal.  It's something Knut implemented.  I think the idea 
was that when running under a debugger, the debugger would break in 
the exception handler without the need to do anything explicit.

> Single stepping, it seems to die very early while trying to figure out 
> the program path and preload xul.dll.

It will be easier to see what's going on once you have some debug data
in place.  If you convert the CS:EIP=005b:0d970002 exception address 
to a source code file and line number, I can take a look at what's 
going on.

Steven

-- 
---------------------------------------------------------------------
Steven Levine <steve53@earthlink.bogus.net>
eCS/Warp/DIY etc. www.scoug.com www.ecomstation.com
---------------------------------------------------------------------
0
Steven
11/19/2012 7:03:17 AM
On Mon, 19 Nov 2012 01:58:56 UTC, Felix Miata 
<UgaddaBkidding.due2UCE@dev.nul> wrote:

HI,

> First "crash" since installing libc065.xqs produced only black where windows 
> belong on return from SVGA fullscreen DOS, "infinitely" pegged CPU, no *.TRP, 
> only speaker beep from clicking on shutdown icon, and CAD only recourse to 
> get system control back.

Interesting.  You are the first to report a failure like this.   If it
recurs, I recommend you move the libc065.xqs files out of the way.

Steven





-- 
---------------------------------------------------------------------
Steven Levine <steve53@earthlink.bogus.net>
eCS/Warp/DIY etc. www.scoug.com www.ecomstation.com
---------------------------------------------------------------------
0
Steven
11/19/2012 7:12:03 AM
Steven Levine wrote:
> On Sun, 18 Nov 2012 23:17:35 UTC, Dave Yeo<dave.r.yeo@gmail.com>
> wrote:
>
> Hi,
>
>> >  Doing a test just now, -g is added to the compile line but now linking
>> >  has a -s added and starting the binary in a debugger gives nothing but
>> >  assembly.
>> >  Does wlink need something like -g?
> Yes and the -s needs to go away since that is probably part of what is
> stripping the debug data.  I'm not 100% sure on the -s statement.  I'd
> have to look at the emxomfld code to see how it passes the -s through
> to wlink.

The -s went away with --disable-optimize. Without -s or -S emxomfld 
writes a response file with "DEBUG HLL\n" as the first line which is why 
I didn't see anything on the command line.
Dave
0
Dave
11/19/2012 7:13:01 AM
Steven Levine wrote:
> It will be easier to see what's going on once you have some debug data
> in place.  If you convert the CS:EIP=005b:0d970002 exception address
> to a source code file and line number, I can take a look at what's
> going on.

How to convert?
Dave
0
Dave
11/19/2012 7:54:21 AM
On Mon, 19 Nov 2012 07:54:21 UTC, Dave Yeo <dave.r.yeo@gmail.com> 
wrote:

> > It will be easier to see what's going on once you have some debug data
> > in place.  If you convert the CS:EIP=005b:0d970002 exception address
> > to a source code file and line number, I can take a look at what's
> > going on.

> How to convert?

It depends.  Can I assume the the exception occurs before exceptq has 
installed itself?

Basically you have to do what idebug or exceptq would do for you.  You
determine the DLL and the object where the exception occurred and 
subtract the object load address from the exception address to get an 
offset.  With a map file, you can convert the offset to a function 
name and offset within the function.

However, if you have a process dump, you can get pmdf to do the work 
for you.  I recommend you capture a process dump of the failure.  If 
you don't already have it, grab  

  http://home.earthlink.net/~steve53/os2diags/PDumpCtl-20120821.zip

Use

   PDumpCtl r firefox

to set up for a default dump.  Run firefox and after you have a 
process dump, use

  pDumpCtl o

to turn off the dump facility.

If you don't have pmdf configured from your system, see

  http://home.earthlink.net/~steve53/os2diags/ProcDumpRef.txt

Open the dump file in pmdf and try the dump formatter commands

  r
  ln
  u

Depending on how well you set up pmdf, you might get a function name, 
the offset within the function and a disassembly of the code that 
trapped.

If you need pmdf setup help, perhaps we should get together on IRC to 
walk through the process.

Steven

-- 
---------------------------------------------------------------------
Steven Levine <steve53@earthlink.bogus.net>
eCS/Warp/DIY etc. www.scoug.com www.ecomstation.com
---------------------------------------------------------------------
0
Steven
11/19/2012 6:19:23 PM
On 11/19/12 10:19 am, Steven Levine wrote:
> On Mon, 19 Nov 2012 07:54:21 UTC, Dave Yeo<dave.r.yeo@gmail.com>
> wrote:
>
>>> It will be easier to see what's going on once you have some debug data
>>> in place.  If you convert the CS:EIP=005b:0d970002 exception address
>>> to a source code file and line number, I can take a look at what's
>>> going on.
>
>> How to convert?
>
> It depends.  Can I assume the the exception occurs before exceptq has
> installed itself?
>
> Basically you have to do what idebug or exceptq would do for you.  You
> determine the DLL and the object where the exception occurred and
> subtract the object load address from the exception address to get an
> offset.  With a map file, you can convert the offset to a function
> name and offset within the function.
>
> However, if you have a process dump, you can get pmdf to do the work
> for you.  I recommend you capture a process dump of the failure.  If
> you don't already have it, grab
>
>    http://home.earthlink.net/~steve53/os2diags/PDumpCtl-20120821.zip
>
> Use
>
>     PDumpCtl r firefox
>
> to set up for a default dump.  Run firefox and after you have a
> process dump, use
>
>    pDumpCtl o
>
> to turn off the dump facility.
>
> If you don't have pmdf configured from your system, see
>
>    http://home.earthlink.net/~steve53/os2diags/ProcDumpRef.txt
>
> Open the dump file in pmdf and try the dump formatter commands
>
>    r
>    ln
>    u
>
> Depending on how well you set up pmdf, you might get a function name,
> the offset within the function and a disassembly of the code that
> trapped.
>
> If you need pmdf setup help, perhaps we should get together on IRC to
> walk through the process.
>

OK, I get 2 dump files. Now I guess I need the sym files. Running 
mapsymw.pl results in
R:\tmp>perl mapsymw.pl -v -d brwsrcmp.map


Processing brwsrcmp
Can not locate module name.  brwsrcmp.map is probably not a Watcom map file

and a 0 byte brwsrcmp.map. Mapsymw.pl is 10843 bytes dated 03/19/12.
I take it the sym files will go to \os2\pdpsi\pmdf\warp45_s?
Dave

0
Dave
11/19/2012 11:17:03 PM
Dave Yeo wrote:
> OK, I get 2 dump files. Now I guess I need the sym files. Running
> mapsymw.pl results in
> R:\tmp>perl mapsymw.pl -v -d brwsrcmp.map

Different perl install does seem to work though it is slow :)
Processing xul.map (xul.dll is 237MBs and xul.map is 32 MBs)
Processing xul
Processed 32 segments and 388810 symbols for xul

Operating System/2 Symbol File Generator
Version 4.00.000 Oct  4 2001
Copyright (C) IBM Corporation 1988-2001
Copyright (C) Microsoft Corp. 1988-1991.
All rights reserved.


No entry point, assume 0000:0100
Warning: Group-relative offsets in TEXT32 exceed 64K limit.

32 segments seems excessive and I wonder if it is limited by a signed short?
Dave
0
Dave
11/20/2012 3:23:29 AM
Dave Yeo wrote:
> No entry point, assume 0000:0100
> Warning: Group-relative offsets in TEXT32 exceed 64K limit.

Finished after 40 minutes with another similar warning about DATA32
Dave
0
Dave
11/20/2012 4:24:03 AM
On Mon, 19 Nov 2012 23:17:03 UTC, Dave Yeo <dave.r.yeo@gmail.com> 
wrote:

Hi Dave,

> 
> OK, I get 2 dump files. Now I guess I need the sym files. Running 
> mapsymw.pl results in
> R:\tmp>perl mapsymw.pl -v -d brwsrcmp.map
> Processing brwsrcmp
> Can not locate module name.  brwsrcmp.map is probably not a Watcom map file
> and a 0 byte brwsrcmp.map. Mapsymw.pl is 10843 bytes dated 03/19/12.
> I take it the sym files will go to \os2\pdpsi\pmdf\warp45_s?

Yes.  They go in the directory for your kernel version which should be
pointed to by pmdfvers.lst.  You may need to edit pmdfvers.lst so that
it looks in warp45_s for your kernel version.

Steven

-- 
---------------------------------------------------------------------
Steven Levine <steve53@earthlink.bogus.net>
eCS/Warp/DIY etc. www.scoug.com www.ecomstation.com
---------------------------------------------------------------------
0
Steven
11/20/2012 8:17:14 AM
On Tue, 20 Nov 2012 03:23:29 UTC, Dave Yeo <dave.r.yeo@gmail.com> 
wrote:

Hi Dave,

> Different perl install does seem to work though it is slow :)

These days I run perl 5.16.0.

> Processing xul.map (xul.dll is 237MBs and xul.map is 32 MBs)

This is a huge map file and it surely contain more symbols than mapsym
or pmdf can handle.  You need to take an educated guess where the 
exception address is an remove symbols you can live without.

> No entry point, assume 0000:0100
> Warning: Group-relative offsets in TEXT32 exceed 64K limit.

When the warning goes away you will know you have removed enough 
symbols.  To get the load address of xul.dll, use

  .lmo "xul"

The executable 32-bit code is in object 1, so subtract the load 
address of object 1 from the exception address and you will have the 
offset of the exception relative to the object.  Once you have this 
you can find the function in the map or if you built a sym file, the 
pmdf ln command will do the math for you.

> 32 segments seems excessive and I wonder if it is limited by a signed short?

It's not excessive - these are 64KB segments.  However, it is beyond 
the limits of .sym files.  This is one of the reasons Rich implemented
..xqs files.  Xqs files are 32-bit and they are more efficient to index.

Steven

-- 
---------------------------------------------------------------------
Steven Levine <steve53@earthlink.bogus.net>
eCS/Warp/DIY etc. www.scoug.com www.ecomstation.com
---------------------------------------------------------------------
0
Steven
11/20/2012 8:44:24 AM
Reply: