[New] FF and SM with Native Printing Support

Full-featured native printing support in Firefox and Seamonkey is now
available for testing.  You can get these betas from:

* Firefox v4.0.2pre:
    ftp://ftp.netlabs.org/incoming/mozilla/firefox-20110702.zip
  or
    http://e-vertise.com/warpzilla/firefox-20110702.zip
 
* Seamonkey v2.1:
    ftp://ftp.netlabs.org/incoming/mozilla/seamonkey-20110703.zip
  or
    http://e-vertise.com/warpzilla/seamonkey-20110703.zip

New
---
All features offered by your printer driver (e.g. duplexing) should
be fully functional.  In addition, your printer's output resolution
is no longer limited to conserve memory.  In most cases, you should
be able to print at higher resolutions while using less memory than
previously.  Please see 'Notes' below for more info.

Fixed
-----
Both apps will now run on systems where dive.dll is not present.
If it is available, it will be loaded to provide improved video
performance for users of SNAP and GenGradd.

Notes
-----
General:  This is the second phase of a project sponsored by Mensys
to provide printing support in the Mozilla apps.  Unlike Phase I
where the app created the printed output dot-by-dot, this version
uses native graphics commands that are interpreted by your printer's
driver to create the final output.

Postscript:  If you've been using the built-in Postscript generator
and would like to switch to OS/2's native PS printer driver, type
"about:config" in the URL bar and press 'Enter'.  Doubleclick on
the entry for "print.os2.postscript.use_builtin" to change it from
'true' to 'false'.  If this entry is missing, the app will default
to the native driver.

Postscript to PDF:  This version should produce high quality output
when directed to a printer.  However, its output may not be suitable
for conversion to PDF because all text is handled as graphics rather
than characters that can be selected.  Instead, you can either use
the app's built-in PDF capabilities (select "Print to File", then
give the filename a 'pdf' extension) or you can print to file using
the app's Postscript generator (select a non-Postscript printer
driver, click "Print to File", then give the file a 'ps' extension).

Bug(?):  If nothing prints the very first time you try, close the
app, reopen it, then retry.  It should not fail again.

Support
-------
Community support for these betas and all Mozilla apps is available
through the newsgroups 'mozilla.dev.ports.os2' or 'comp.os.os2.apps'.
Messages posted to other forums may not be seen by the developers.


Rich Walsh <richATe-vertiseDOTcom>


-- 
== == almost usable email address:  Rich AT E-vertise DOT Com == ==

0
Rich
7/4/2011 3:32:42 AM
mozilla.dev.ports.os2 2335 articles. 0 followers. Post Follow

119 Replies
847 Views

Similar Articles

[PageSpeed] 13

On 07/03/11 08:32 pm, Rich Walsh wrote:

> Full-featured native printing support in Firefox and Seamonkey is now
> available for testing.

Is it fully functional for mail/news now, or does that still require 
using print preview?

0
Steve
7/4/2011 6:24:24 AM
Sometimes I download things and test them, sometimes they collect some dust in 
between. For others in this situation, the more accurate the readmes, etc. are, 
the better. So, if you have the time...

 From this release readme:

- Software requirements
....
   + Only Java plugins of version 1.4.1 or 1.4.2 are supported.
     (IBM Java 1.3.1 or earlier will crash the application!)
....

I think this is no longer true.

And for a printing-centered release I'd rather have your post text than this:

....
- Printing to normal OS/2 printer queues had to be disabled. It was slow even
   for simple pages and used huge amounts of RAM, so that in most cases the
   application crashed, see https://bugzilla.mozilla.org...
   While the queues are still displayed in the printing dialog, any printing
   operation will instead create a PDF file. By default this file is placed on
   the Desktop, with the name SeaMonkey_<date>_<time>.pdf, where <date> and
   <time> are replaced by the current system time. If you want to use another
   name, select "Print to file" before pressing the Print button.
   The resulting PDF file can be printed using applications like Lucide,
....

I've fixed the readme in my copy.

Hopefully I'll be able to produce text-based postscript files now?!? Good!

Anyway, thanks for your work on this!!!!

0
ISO
7/4/2011 11:48:59 AM
Made a quick test with page www.wetator.org


07-04-2011  18:43:11  SYS3175  PID 0031  TID 0001  Slot 0071
D:\PROGS\WEB\FIREFOX-20110702\FIREFOX.EXE
c0000005
1e8a2db3
P1=00000001  P2=19f83828  P3=XXXXXXXX  P4=XXXXXXXX
EAX=19f837e8  EBX=00000001  ECX=00000000  EDX=19fd7940
ESI=00000001  EDI=19fd7940
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:1e8a2db3  CSACC=f0df  CSLIM=ffffffff
SS:ESP=0053:0012fe14  SSACC=f0f3  SSLIM=ffffffff
EBP=0012fe30  FLG=00010206

PMMERGE.DLL 0004:00072db3

eCS 20; no flash, printer HP Laserjet 4; 600dpi

Send me a mail if you need more info.
0
rbri
7/4/2011 4:47:28 PM
rbri wrote:
> Made a quick test with pagewww.wetator.org
>
>
> 07-04-2011  18:43:11  SYS3175  PID 0031  TID 0001  Slot 0071
> D:\PROGS\WEB\FIREFOX-20110702\FIREFOX.EXE
> c0000005

Were you previously running FF4?
Dave
0
Dave
7/4/2011 6:31:53 PM
Sir:

Rich Walsh wrote:
>
> Full-featured native printing support in Firefox and Seamonkey is now
> available for testing.  You can get these betas from:
>
> * Firefox v4.0.2pre:
>      ftp://ftp.netlabs.org/incoming/mozilla/firefox-20110702.zip
>    or
>      http://e-vertise.com/warpzilla/firefox-20110702.zip
>
> * Seamonkey v2.1:
>      ftp://ftp.netlabs.org/incoming/mozilla/seamonkey-20110703.zip
>    or
>      http://e-vertise.com/warpzilla/seamonkey-20110703.zip
>
> New
> ---
> All features offered by your printer driver (e.g. duplexing) should
> be fully functional.  In addition, your printer's output resolution
> is no longer limited to conserve memory.  In most cases, you should
> be able to print at higher resolutions while using less memory than
> previously.  Please see 'Notes' below for more info.
>
> Fixed
> -----
> Both apps will now run on systems where dive.dll is not present.
> If it is available, it will be loaded to provide improved video
> performance for users of SNAP and GenGradd.
>
> Notes
> -----
> General:  This is the second phase of a project sponsored by Mensys
> to provide printing support in the Mozilla apps.  Unlike Phase I
> where the app created the printed output dot-by-dot, this version
> uses native graphics commands that are interpreted by your printer's
> driver to create the final output.
>
> Postscript:  If you've been using the built-in Postscript generator
> and would like to switch to OS/2's native PS printer driver, type
> "about:config" in the URL bar and press 'Enter'.  Doubleclick on
> the entry for "print.os2.postscript.use_builtin" to change it from
> 'true' to 'false'.  If this entry is missing, the app will default
> to the native driver.
>
> Postscript to PDF:  This version should produce high quality output
> when directed to a printer.  However, its output may not be suitable
> for conversion to PDF because all text is handled as graphics rather
> than characters that can be selected.  Instead, you can either use
> the app's built-in PDF capabilities (select "Print to File", then
> give the filename a 'pdf' extension) or you can print to file using
> the app's Postscript generator (select a non-Postscript printer
> driver, click "Print to File", then give the file a 'ps' extension).
>
> Bug(?):  If nothing prints the very first time you try, close the
> app, reopen it, then retry.  It should not fail again.
>
> Support
> -------
> Community support for these betas and all Mozilla apps is available
> through the newsgroups 'mozilla.dev.ports.os2' or 'comp.os.os2.apps'.
> Messages posted to other forums may not be seen by the developers.

Thanks, it works and is much faster than SeaMonkey 2.0.4 was on this 
resource constrained system.

What is Sync?
-- 
Bill
Thanks a Million!
0
William
7/4/2011 7:04:22 PM
On 7/4/2011 12:04 PM, William L. Hartzell wrote:

> What is Sync?

https://services.mozilla.com/
0
Steve
7/4/2011 7:12:32 PM
On Jul 4, 8:31=A0pm, Dave Yeo <dave.r....@gmail.com> wrote:
> rbri wrote:
> > Made a quick test with page www.wetator.org
>
> > 07-04-2011 =A018:43:11 =A0SYS3175 =A0PID 0031 =A0TID 0001 =A0Slot 0071
> > D:\PROGS\WEB\FIREFOX-20110702\FIREFOX.EXE
> > c0000005
>
> Were you previously running FF4?
> Dave

Did a reboot before the test.
0
rbri
7/4/2011 7:13:19 PM
Rich,

On Sun, 03 Jul 2011 22:32:42 -0500, Rich Walsh wrote:

>
>Full-featured native printing support in Firefox and Seamonkey is now
>available for testing.  You can get these betas from:
>
>* Firefox v4.0.2pre:
>    ftp://ftp.netlabs.org/incoming/mozilla/firefox-20110702.zip
>  or
>    http://e-vertise.com/warpzilla/firefox-20110702.zip
> 
>* Seamonkey v2.1:
>    ftp://ftp.netlabs.org/incoming/mozilla/seamonkey-20110703.zip
>  or
>    http://e-vertise.com/warpzilla/seamonkey-20110703.zip
>

  Thanks for these new builds! I'm primarily using SeaMonkey and printing
seems to work well with this new version. I still get many seemingly random
crashes in TCPIP32... I've got 8 so far since using it for about an hour. Is
this normal?

Regards.

Dave McKenna



0
David
7/4/2011 7:33:59 PM
David McKenna wrote: >    Thanks for these new builds! I'm primarily 
using SeaMonkey and printing > seems to work well with this new version. 
I still get many seemingly random > crashes in TCPIP32... I've got 8 so 
far since using it for about an hour. Is > this normal?
No. What is your virtualaddresslimit? Are you running Flash?
Dave
0
Dave
7/4/2011 8:34:05 PM
Dave Yeo wrote: > David McKenna wrote: > Thanks for these new builds! 
I'm primarily using > SeaMonkey and printing > seems to work well with 
this new version. I > still get many seemingly random > crashes in 
TCPIP32... I've got 8 so > far since using it for about an hour. Is > 
this normal? > No. What is your virtualaddresslimit? Are you running 
Flash? > Dave
Strange, I seem to have lost line endings when quoting but after 
sending. Not Rich's build.
Dave
0
Dave
7/4/2011 8:58:43 PM
Dave,

On Mon, 04 Jul 2011 13:34:05 -0700, Dave Yeo wrote:

>David McKenna wrote: >    Thanks for these new builds! I'm primarily 
>using SeaMonkey and printing > seems to work well with this new version. 
>I still get many seemingly random > crashes in TCPIP32... I've got 8 so 
>far since using it for about an hour. Is > this normal?
>No. What is your virtualaddresslimit? Are you running Flash?
>Dave

  VIRTUALADDRESSLIMIT=1536

  I have tried with and without Flash, but it seems to make no difference
with these particular crashes. With Flash I get lots of hangs, but crashes
don't seem to change much. I usually do not run other software when using
SeaMonkey.

  I'm running eCS 2.1 on an Intel i3 based machine in SMP mode with 2GB RAM.

Dave McKenna



0
David
7/4/2011 10:26:38 PM
On Mon, 4 Jul 2011 19:33:59 UTC, "David McKenna" <davidmckenna@comcast.net> wrote:

> I still get many seemingly random crashes in TCPIP32... I've got 8
> so far since using it for about an hour. Is this normal?

Many betas ago, people would report these traps in TCPIP32 but I'd never
get them.  These days, it's a regular occurrence.

BTW... I doubt that there's an external cause for them.  It's either
Mozilla's fault (likely) or a bug in TCPIP that Mozilla exposes
(unlikely).  I'll try to find out.


-- 
== == almost usable email address:  Rich AT E-vertise DOT Com == ==

0
Rich
7/5/2011 1:10:14 AM
On Mon, 4 Jul 2011 06:24:24 UTC, Steve Wendt <spamsux@forgetit.org> wrote:

> On 07/03/11 08:32 pm, Rich Walsh wrote:
> 
> > Full-featured native printing support in Firefox and Seamonkey is now
> > available for testing.
> 
> Is it fully functional for mail/news now, or does that still require 
> using print preview?

You have to use print preview.  Is this an issue on other platforms?


-- 
== == almost usable email address:  Rich AT E-vertise DOT Com == ==

0
Rich
7/5/2011 1:11:16 AM
On 7/4/2011 6:11 PM, Rich Walsh wrote:

>>> Full-featured native printing support in Firefox and Seamonkey is now
>>> available for testing.
>>
>> Is it fully functional for mail/news now, or does that still require
>> using print preview?
>
> You have to use print preview.  Is this an issue on other platforms?

Not that I am aware of.
0
Steve
7/5/2011 1:20:46 AM
Sir:

Steve Wendt wrote:
> On 7/4/2011 12:04 PM, William L. Hartzell wrote:
>
>> What is Sync?
>
> https://services.mozilla.com/

So it is a cloud way to keep multiple machines's bookmarks, history, 
passwords, etc. in one location.  That is a solution to what the others 
have been grousing about with their bookmarks?
-- 
Bill
Thanks a Million!
0
William
7/5/2011 4:03:33 PM
On 7/5/2011 9:03 AM, William L. Hartzell wrote:

>>> What is Sync?
>>
>> https://services.mozilla.com/
>
> So it is a cloud way to keep multiple machines's bookmarks, history,
> passwords, etc. in one location. That is a solution to what the others
> have been grousing about with their bookmarks?

It's one solution, yes.  It replaces roaming profiles, which Firefox 
never supported.
0
Steve
7/5/2011 5:13:12 PM
Sir:

Steve Wendt wrote:
> On 7/5/2011 9:03 AM, William L. Hartzell wrote:
>
>>>> What is Sync?
>>>
>>> https://services.mozilla.com/
>>
>> So it is a cloud way to keep multiple machines's bookmarks, history,
>> passwords, etc. in one location. That is a solution to what the others
>> have been grousing about with their bookmarks?
>
> It's one solution, yes. It replaces roaming profiles, which Firefox
> never supported.
Can one put their profile on the cloud and have OS/2 version of 
SeaMonkey/Firefox/Thunderbird/Sunbird, etc. use it?  How would one 
replace the config.sys indicated profile folder?
-- 
Bill
Thanks a Million!
0
William
7/5/2011 6:23:31 PM
Rich Walsh schrieb:
> On Mon, 4 Jul 2011 19:33:59 UTC, "David McKenna"<davidmckenna@comcast.net>  wrote:
>
>> I still get many seemingly random crashes in TCPIP32... I've got 8
>> so far since using it for about an hour. Is this normal?
>
> Many betas ago, people would report these traps in TCPIP32 but I'd never
> get them.  These days, it's a regular occurrence.
>
> BTW... I doubt that there's an external cause for them.  It's either
> Mozilla's fault (likely) or a bug in TCPIP that Mozilla exposes
> (unlikely).  I'll try to find out.
>
>
Does it help to upload *.TRP somewhere? I just got on in TCPIP32 with SM2.1 
(Build-Identifikator: Mozilla/5.0 (OS/2; Warp 4.5; rv:2.0.1) Gecko/20110513 
Firefox/4.0.1 SeaMonkey/2.1)

Regards,
Andi

0
Andreas
7/5/2011 7:37:25 PM
On 7/5/2011 11:23 AM, William L. Hartzell wrote:

>>> So it is a cloud way to keep multiple machines's bookmarks, history,
>>> passwords, etc. in one location. That is a solution to what the others
>>> have been grousing about with their bookmarks?
>
> Can one put their profile on the cloud and have OS/2 version of
> SeaMonkey/Firefox/Thunderbird/Sunbird, etc. use it? How would one
> replace the config.sys indicated profile folder?

I haven't used it personally, but as I understand it, you still need a 
profile.  You just sync the selected bits of information to/from the 
"cloud", not the entire profile.
0
Steve
7/5/2011 7:46:01 PM
On Tue, 5 Jul 2011 19:37:25 UTC, Andreas Buchinger <andi.b@gmx.net> wrote:

> Does it help to upload *.TRP somewhere? I just got on in TCPIP32 with SM2.1 
> (Build-Identifikator: Mozilla/5.0 (OS/2; Warp 4.5; rv:2.0.1) Gecko/20110513 
> Firefox/4.0.1 SeaMonkey/2.1)

At this point, we have a lot of reports for TCPIP32, so another one wouldn't
be of much help.  We know where the crash occurs, we just don't know why. :-(

If you experience _other_ crashes on a regular basis, send the reports to
crashATe-vertise.com.



-- 
== == almost usable email address:  Rich AT E-vertise DOT Com == ==

0
Rich
7/5/2011 11:26:01 PM
BTW...  I forgot to mention that you shouldn't see oversized scrollbars in
print preview anymore.  If you do (or if they're too small), let me know.


-- 
== == almost usable email address:  Rich AT E-vertise DOT Com == ==

0
Rich
7/5/2011 11:30:43 PM
On 7/5/2011 4:30 PM, Rich Walsh wrote:

> BTW...  I forgot to mention that you shouldn't see oversized scrollbars in
> print preview anymore.  If you do (or if they're too small), let me know.

This is for all themes, or just the default one?
0
Steve
7/6/2011 12:52:32 AM
On 07/05/11 05:52 pm, Steve Wendt wrote:

>> BTW... I forgot to mention that you shouldn't see oversized scrollbars in
>> print preview anymore. If you do (or if they're too small), let me know.
>
> This is for all themes, or just the default one?

Still "too small" for me, non-default theme (Gray Modern).  But that is 
probably to be expected.
https://bugzilla.mozilla.org/show_bug.cgi?id=399671
0
Steve
7/6/2011 3:10:32 AM
On 07/05/11 08:10 pm, Steve Wendt wrote:

>>> BTW... I forgot to mention that you shouldn't see oversized
>>> scrollbars in print preview anymore. If you do (or if they're too
>>> small), let me know.
>
> Still "too small" for me, non-default theme (Gray Modern).

Exactly the same in the default theme - sorry.
0
Steve
7/6/2011 3:13:02 AM
On 07/03/11 08:32 pm, Rich Walsh wrote:

> Postscript:  If you've been using the built-in Postscript generator
> and would like to switch to OS/2's native PS printer driver, type
> "about:config" in the URL bar and press 'Enter'.  Doubleclick on
> the entry for "print.os2.postscript.use_builtin" to change it from
> 'true' to 'false'.

For what it's worth, the "built-in" version still seems to generate 
better print quality on my HP Laserjet.  Does the "use_ibmnull" option 
still do anything?  In both cases, it was set to true.
0
Steve
7/6/2011 3:23:50 AM
On Wed, 6 Jul 2011 03:13:02 UTC, Steve Wendt <spamsux@forgetit.org> wrote:
> On 07/05/11 08:10 pm, Steve Wendt wrote:
> 
> >>> BTW... I forgot to mention that you shouldn't see oversized
> >>> scrollbars in print preview anymore. If you do (or if they're too
> >>> small), let me know.
> >
> > Still "too small" for me, non-default theme (Gray Modern).
> 
> Exactly the same in the default theme - sorry.

On my system, using either theme:
 - at 96dpi, the scrollbars in Print Preview are identical to those in
   a browser window
 - at 120dpi, Print Preview's scrollbars are 25% larger than the browser's
   scrollbars (i.e. (1 - 120/96)% )

Unlike before, they no longer vary depending on the printer's dpi setting.

BTW... my goal was less to get the scrollbars right than to ensure that
widgets on a web page (e.g. pushbuttons) were correctly sized when printed.


-- 
== == almost usable email address:  Rich AT E-vertise DOT Com == ==

0
Rich
7/6/2011 12:45:16 PM
On 2011/07/06 07:45 (GMT-0500) Rich Walsh composed:

> On my system, using either theme:

>  - at 96dpi, the scrollbars in Print Preview are identical to those in
>    a browser window
>  - at 120dpi, Print Preview's scrollbars are 25% larger than the browser's
>    scrollbars (i.e. (1 - 120/96)% )

> Unlike before, they no longer vary depending on the printer's dpi setting.

> BTW... my goal was less to get the scrollbars right than to ensure that
> widgets on a web page (e.g. pushbuttons) were correctly sized when printed.

Printing from rv1.9-up on Linux @more than 96 DPI has been dismal. Everything
is inflated, and form controls more so. It's absolutely nuts how incompetent it
is, though less bad if a print-specific stylesheet sizing in pt is used by the
page to be printed, which is hardly a universal feature of typical web sites.

On eCS, ever since replacing my LJ4 with a Canon MF4370dn and dropping SM
1.1.19 for 2.1, I haven't much thought about figuring out to print from OS/2
again. Canon doesn't support US Linux users, even though the box mine came in
expressly says it does. I have to goto its UK web site for drivers, which (v2.2
or prior) don't work in any latest Linux versions at all (e.g. Fedora 15,
openSUSE 11.4), apparently incompatible with some recent CUPS changes. Luckily
I'm still in openSUSE 11.2 on this machine, where the latest proprietary driver
does work.
-- 
"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
7/6/2011 4:08:41 PM
On 06.07.2011 01:26, Rich Walsh wrote:

> At this point, we have a lot of reports for TCPIP32, so another one wouldn't
> be of much help.  We know where the crash occurs, we just don't know why. :-(

So, where does it occur? This frequent crash was one of the reasons why I never
took up again.
   Peter.
0
Peter
7/7/2011 12:57:15 PM
For those with a TCPIP32 problem try using this TCP/IP stack,
the final one for OS/2 from June 2007.

http://www.os2site.com/sw/upgrades/tcpip/tcpip32_stack.zip

It's only problem is a memory leak if you use the syncookie option,
see the enclosed readme.txt file.

I'm not sure what eComStation use's.

Cheers
0
Ian
7/7/2011 4:52:08 PM
Ian,

On Thu, 7 Jul 2011 09:52:08 -0700 (PDT), Ian Manners wrote:

>For those with a TCPIP32 problem try using this TCP/IP stack,
>the final one for OS/2 from June 2007.
>
>http://www.os2site.com/sw/upgrades/tcpip/tcpip32_stack.zip
>
>It's only problem is a memory leak if you use the syncookie option,
>see the enclosed readme.txt file.
>
>I'm not sure what eComStation use's.
>
>Cheers

 Thanks for the link... it doesn't seem to help any here with SeaMonkey 2.1
and TCPIP32 crashes though. It also seems only one file is different from
what is on eCS 2.1 (at least by file size) - afinetk.sys. Any idea what this
was intended to fix (or add)?

Regards,

Dave McKenna



0
David
7/7/2011 9:38:24 PM
On Tue, 5 Jul 2011 23:26:01 UTC, "Rich Walsh" <spamyourself@127.0.0.1>
wrote:

Hi,

> At this point, we have a lot of reports for TCPIP32, so another one wouldn't
> be of much help.  We know where the crash occurs, we just don't know why. :-(

I don't get traps in TCPIP32 here.  Would it help if I took a look at 
a process dump?

Steven

-- 
---------------------------------------------------------------------
Steven Levine <steve53@earthlink.bogus.net>
eCS/Warp/DIY etc. www.scoug.com www.ecomstation.com
---------------------------------------------------------------------
0
Steven
7/8/2011 1:11:10 AM
On Thu, 7 Jul 2011 21:38:24 UTC, "David McKenna" <davidmckenna@comcast.net> wrote:
> On Thu, 7 Jul 2011 09:52:08 -0700 (PDT), Ian Manners wrote:
> 
> >For those with a TCPIP32 problem try using this TCP/IP stack,
> >the final one for OS/2 from June 2007.
> >
> >http://www.os2site.com/sw/upgrades/tcpip/tcpip32_stack.zip
> >
> >It's only problem is a memory leak if you use the syncookie option,
> >see the enclosed readme.txt file.
> 
>  Thanks for the link... it doesn't seem to help any here with SeaMonkey 2.1
> and TCPIP32 crashes though. It also seems only one file is different from
> what is on eCS 2.1 (at least by file size) - afinetk.sys. Any idea what this
> was intended to fix (or add)?

I compared each file in the zip with what was on my eCS 2.0 system and found
three updated files (as always, the timestamps on the files are meaningless):
  afinet.sys
  afinetk.sys
  aflean.sys

I've installed these (afinetk.sys is the only one that's actually used) but
I doubt it will help me any more than it helped Dave.  I'm pretty sure the
problem is in Moz (I never got these crashes until fairly late in the FF 4
development cycle).


-- 
== == almost usable email address:  Rich AT E-vertise DOT Com == ==

0
Rich
7/8/2011 4:21:40 AM
On Fri, 8 Jul 2011 01:11:10 UTC, "Steven Levine" wrote:
> On Tue, 5 Jul 2011 23:26:01 UTC, "Rich Walsh" wrote:
> 
> > At this point, we have a lot of reports for TCPIP32, so another one wouldn't
> > be of much help.  We know where the crash occurs, we just don't know why. :-(
> 
> I don't get traps in TCPIP32 here.  Would it help if I took a look at 
> a process dump?

Absolutely!  Since Dave McKenna gets 8 of these crashes an hour, perhaps
he'd be willing to create a dump.  How about it, Dave?

FWIW... my suspicion (as yet untested) in that we're passing a null data
buffer to some of the functions in 'nsprpub\pr\src\md\os2\os2sock.c'.


-- 
== == almost usable email address:  Rich AT E-vertise DOT Com == ==

0
Rich
7/8/2011 4:27:46 AM
Rich... Steve,

On Thu, 07 Jul 2011 23:27:46 -0500, Rich Walsh wrote:

>On Fri, 8 Jul 2011 01:11:10 UTC, "Steven Levine" wrote:
>> On Tue, 5 Jul 2011 23:26:01 UTC, "Rich Walsh" wrote:
>> 
>> > At this point, we have a lot of reports for TCPIP32, so another one wouldn't
>> > be of much help.  We know where the crash occurs, we just don't know why. :-(
>> 
>> I don't get traps in TCPIP32 here.  Would it help if I took a look at 
>> a process dump?
>
>Absolutely!  Since Dave McKenna gets 8 of these crashes an hour, perhaps
>he'd be willing to create a dump.  How about it, Dave?
>
>FWIW... my suspicion (as yet untested) in that we're passing a null data
>buffer to some of the functions in 'nsprpub\pr\src\md\os2\os2sock.c'.
>

  I'd be glad to help.... I'll need step-by-step instructions for creating a
process dump since I've never done it before. Is there a good document
somewhere?...

Regards,

Dave McKenna



0
David
7/8/2011 11:14:11 AM
On Fri, 8 Jul 2011 11:14:11 UTC, "David McKenna" <davidmckenna@comcast.net> 
wrote:

> >> I don't get traps in TCPIP32 here.  Would it help if I took a look at 
> >> a process dump?
> >
> >Absolutely!  Since Dave McKenna gets 8 of these crashes an hour, perhaps
> >he'd be willing to create a dump.  How about it, Dave?
> 
>   I'd be glad to help.... I'll need step-by-step instructions for 
> creating a process dump since I've never done it before. Is there a good 
> document somewhere?...

Steve himself has an invaluable guide:
http://home.earthlink.net/~steve53/os2diags/ProcDumpRef.txt

The short form is: run "procdump on /l:path" where path is any 
directory (root or otherwise) on a disk with plenty of space.
Then run the program, allow it to crash, and you should find 
PDUMP.whatever files in that directory.  Run "procdump off" 
afterwards.


-- 
Alex Taylor
Fukushima, Japan
http://www.socis.ca/~ataylo00

Please take off hat when replying.
0
Alex
7/8/2011 11:44:36 AM
Alex,

On Fri, 08 Jul 2011 06:44:36 -0500, Alex Taylor wrote:

>On Fri, 8 Jul 2011 11:14:11 UTC, "David McKenna" <davidmckenna@comcast.net> 
>wrote:
>
>> >> I don't get traps in TCPIP32 here.  Would it help if I took a look at 
>> >> a process dump?
>> >
>> >Absolutely!  Since Dave McKenna gets 8 of these crashes an hour, perhaps
>> >he'd be willing to create a dump.  How about it, Dave?
>> 
>>   I'd be glad to help.... I'll need step-by-step instructions for 
>> creating a process dump since I've never done it before. Is there a good 
>> document somewhere?...
>
>Steve himself has an invaluable guide:
>http://home.earthlink.net/~steve53/os2diags/ProcDumpRef.txt
>
>The short form is: run "procdump on /l:path" where path is any 
>directory (root or otherwise) on a disk with plenty of space.
>Then run the program, allow it to crash, and you should find 
>PDUMP.whatever files in that directory.  Run "procdump off" 
>afterwards.
>

  Thanks for that! I'll do it right away. Where should I send PDUMP once I
have it?

Regards,

Dave McKenna



0
David
7/8/2011 8:57:54 PM
On Fri, 8 Jul 2011 11:44:36 UTC, "Alex Taylor" 
<mail.me@reply.to.address> wrote:

> Steve himself has an invaluable guide:
> http://home.earthlink.net/~steve53/os2diags/ProcDumpRef.txt
 
> The short form is: run "procdump on /l:path" where path is any 
> directory (root or otherwise) on a disk with plenty of space.
> Then run the program, allow it to crash, and you should find 
> PDUMP.whatever files in that directory.  Run "procdump off" 
> afterwards.

We will need a bit more than this.  I doubt that a default dump will 
include what I am need to look at.  Grab

 <http://home.earthlink.net/~steve53/os2diags/PDumpCtl-20110517.zip>

Read pdumpctl.txt and set up for what the it calls an Extended dump.  
This will include both private and shared data.

Steven

-- 
---------------------------------------------------------------------
Steven Levine <steve53@earthlink.bogus.net>
eCS/Warp/DIY etc. www.scoug.com www.ecomstation.com
---------------------------------------------------------------------
0
Steven
7/8/2011 10:14:56 PM
Steven,

On Fri, 08 Jul 2011 17:14:56 -0500, Steven Levine wrote:

>On Fri, 8 Jul 2011 11:44:36 UTC, "Alex Taylor" 
><mail.me@reply.to.address> wrote:
>
>> Steve himself has an invaluable guide:
>> http://home.earthlink.net/~steve53/os2diags/ProcDumpRef.txt
> 
>> The short form is: run "procdump on /l:path" where path is any 
>> directory (root or otherwise) on a disk with plenty of space.
>> Then run the program, allow it to crash, and you should find 
>> PDUMP.whatever files in that directory.  Run "procdump off" 
>> afterwards.
>
>We will need a bit more than this.  I doubt that a default dump will 
>include what I am need to look at.  Grab
>
> <http://home.earthlink.net/~steve53/os2diags/PDumpCtl-20110517.zip>
>
>Read pdumpctl.txt and set up for what the it calls an Extended dump.  
>This will include both private and shared data.
>

 Ah... OK, I just sent Rich a ZIP with a dump using Alex's method. I thought
it seemed rather small :-) I'll study the extended dump doc and create
another.... should I send to Rich as well (it will probably take less than a
half hour to create...)

Regards,

Dave McKenna



0
David
7/8/2011 10:22:28 PM
On Fri, 8 Jul 2011 04:27:46 UTC, "Rich Walsh" <spamyourself@127.0.0.1>
wrote:

Hi Rich,

> Absolutely!  Since Dave McKenna gets 8 of these crashes an hour, perhaps
> he'd be willing to create a dump.  How about it, Dave?
> 
> FWIW... my suspicion (as yet untested) in that we're passing a null data
> buffer to some of the functions in 'nsprpub\pr\src\md\os2\os2sock.c'.

OK.  I'm am going to need the .map files for whatever build David is 
using.

I'll also need the specs for the tag that the build was based on and a
pointer to where any required patches live in case I need to look at 
the sources.

Thanks,

Steven


-- 
---------------------------------------------------------------------
Steven Levine <steve53@earthlink.bogus.net>
eCS/Warp/DIY etc. www.scoug.com www.ecomstation.com
---------------------------------------------------------------------
0
Steven
7/8/2011 10:22:39 PM
Steven,

On Fri, 08 Jul 2011 17:22:39 -0500, Steven Levine wrote:

>On Fri, 8 Jul 2011 04:27:46 UTC, "Rich Walsh" <spamyourself@127.0.0.1>
>wrote:
>
>Hi Rich,
>
>> Absolutely!  Since Dave McKenna gets 8 of these crashes an hour, perhaps
>> he'd be willing to create a dump.  How about it, Dave?
>> 
>> FWIW... my suspicion (as yet untested) in that we're passing a null data
>> buffer to some of the functions in 'nsprpub\pr\src\md\os2\os2sock.c'.
>
>OK.  I'm am going to need the .map files for whatever build David is 
>using.
>
>I'll also need the specs for the tag that the build was based on and a
>pointer to where any required patches live in case I need to look at 
>the sources.
>
>Thanks,
>

  FYI... I am using the build found on
ftp://ftp.netlabs.org/incoming/mozilla/seamonkey-20110703.zip.

Regards,

Dave McKenna



0
David
7/8/2011 10:35:01 PM
Steven,

On Fri, 08 Jul 2011 18:22:28 -0400 (EDT), David McKenna wrote:

>Steven,
>
>On Fri, 08 Jul 2011 17:14:56 -0500, Steven Levine wrote:
>
>>On Fri, 8 Jul 2011 11:44:36 UTC, "Alex Taylor" 
>><mail.me@reply.to.address> wrote:
>>
>>> Steve himself has an invaluable guide:
>>> http://home.earthlink.net/~steve53/os2diags/ProcDumpRef.txt
>> 
>>> The short form is: run "procdump on /l:path" where path is any 
>>> directory (root or otherwise) on a disk with plenty of space.
>>> Then run the program, allow it to crash, and you should find 
>>> PDUMP.whatever files in that directory.  Run "procdump off" 
>>> afterwards.
>>
>>We will need a bit more than this.  I doubt that a default dump will 
>>include what I am need to look at.  Grab
>>
>> <http://home.earthlink.net/~steve53/os2diags/PDumpCtl-20110517.zip>
>>
>>Read pdumpctl.txt and set up for what the it calls an Extended dump.  
>>This will include both private and shared data.
>>
>
> Ah... OK, I just sent Rich a ZIP with a dump using Alex's method. I thought
>it seemed rather small :-) I'll study the extended dump doc and create
>another.... should I send to Rich as well (it will probably take less than a
>half hour to create...)
>

  OK... I now have a 160MB ZIP file with 3 PDUMP files and POPUPLOG and *.TRP
files contained as a result of a TCPIP32 crash. Where do you want it? :-) I
used 'PDumpCtl r x SeaMonkey' to get them.

Dave McKenna



0
David
7/8/2011 11:05:27 PM
On Fri, 8 Jul 2011 22:35:01 UTC, "David McKenna" 
<davidmckenna@comcast.net> wrote:

Hi David,

I have sent FTP upload instructions privately.

Thanks,

Steven




-- 
---------------------------------------------------------------------
Steven Levine <steve53@earthlink.bogus.net>
eCS/Warp/DIY etc. www.scoug.com www.ecomstation.com
---------------------------------------------------------------------
0
Steven
7/9/2011 2:36:42 AM
On Fri, 8 Jul 2011 23:05:27 UTC, "David McKenna" 
<davidmckenna@comcast.net> wrote:

Hi David,

>   OK... I now have a 160MB ZIP file with 3 PDUMP files and POPUPLOG and *.TRP
> files contained as a result of a TCPIP32 crash. Where do you want it? :-) I
> used 'PDumpCtl r x SeaMonkey' to get them.

That was quick.  Did the exceptions all occur at the same time or did 
the second and third exceptions occur after you restarted Seamonkey?

Thanks,

Steven


-- 
---------------------------------------------------------------------
Steven Levine <steve53@earthlink.bogus.net>
eCS/Warp/DIY etc. www.scoug.com www.ecomstation.com
---------------------------------------------------------------------
0
Steven
7/9/2011 2:39:14 AM
On Fri, 8 Jul 2011 22:22:39 UTC, "Steven Levine" <steve53@nomail.earthlink.net> wrote:
> On Fri, 8 Jul 2011 04:27:46 UTC, "Rich Walsh" <spamyourself@127.0.0.1> wrote:
> 
> > Absolutely!  Since Dave McKenna gets 8 of these crashes an hour, perhaps
> > he'd be willing to create a dump.  How about it, Dave?
> > 
> > FWIW... my suspicion (as yet untested) in that we're passing a null data
> > buffer to some of the functions in 'nsprpub\pr\src\md\os2\os2sock.c'.
> 
> OK.  I'm am going to need the .map files for whatever build David is 
> using.

All of 'em?  Any chance 'mapxqs -d' would provide equivalent info?
 
> I'll also need the specs for the tag that the build was based on

  http://hg.mozilla.org/releases/comm-2.0/
  http://hg.mozilla.org/releases/mozilla-2.0/

> and a pointer to where any required patches live in case I need
> to look at the sources.

I can send you my patch queue but I've already modified everything
involving printing.  However, the stuff you're likely to look at
(nspr, necko) has not been patched except for the addition of
Exceptq to nspr.  I'll send them Saturday morning.


-- 
== == almost usable email address:  Rich AT E-vertise DOT Com == ==

0
Rich
7/9/2011 4:35:40 AM
On Sat, 9 Jul 2011 04:35:40 UTC, "Rich Walsh" <spamyourself@127.0.0.1>
wrote:

Hi Rich,

> All of 'em?  Any chance 'mapxqs -d' would provide equivalent info?

That should be good enough.  I'll whip up something like like an 
xql2map.pl to reformat the output to be mapsym compatible.  This will 
avoid the need to keep old map files around.

>   http://hg.mozilla.org/releases/comm-2.0/
>   http://hg.mozilla.org/releases/mozilla-2.0/

OK.  Since I already have a clone of

  http://hg.mozilla.org/comm-central/

can I do an hg update to switch to the sources that correspond to your
build (minus patches of course).

> I can send you my patch queue but I've already modified everything
> involving printing.  However, the stuff you're likely to look at
> (nspr, necko) has not been patched except for the addition of
> Exceptq to nspr.  I'll send them Saturday morning.

That will be fine.  I'm still not set up properly to build the current
Mozilla apps, so I'm must looking for reference copies that I can 
correlate to the dump content.

Steven

-- 
---------------------------------------------------------------------
Steven Levine <steve53@earthlink.bogus.net>
eCS/Warp/DIY etc. www.scoug.com www.ecomstation.com
---------------------------------------------------------------------
0
Steven
7/9/2011 5:54:28 AM
On Sat, 9 Jul 2011 05:54:28 UTC, "Steven Levine" wrote:
> On Sat, 9 Jul 2011 04:35:40 UTC, "Rich Walsh" wrote:

> can I do an hg update to switch to the sources that correspond to your
> build (minus patches of course).

I don't know - Dave or Walter know more about this than I do.


The tag for comm-central is:
  changeset:   7691:7f134570dc68
  branch:      COMM201_20110508_RELBRANCH

The tag for mozilla-central is:
  changeset:   63473:f5b873872bcd
  tag:         tip

This tag for m-c may not be available on the trunk but you can
probably use the preceeding one:

  changeset:   63471:b4300fdb3f0e
  branch:      COMM20_053111_RELBRANCH

> > I can send you my patch queue

Done.


-- 
== == almost usable email address:  Rich AT E-vertise DOT Com == ==

0
Rich
7/9/2011 12:40:30 PM
Steven,

On Fri, 08 Jul 2011 21:39:14 -0500, Steven Levine wrote:

>On Fri, 8 Jul 2011 23:05:27 UTC, "David McKenna" 
><davidmckenna@comcast.net> wrote:
>
>Hi David,
>
>>   OK... I now have a 160MB ZIP file with 3 PDUMP files and POPUPLOG and *.TRP
>> files contained as a result of a TCPIP32 crash. Where do you want it? :-) I
>> used 'PDumpCtl r x SeaMonkey' to get them.
>
>That was quick.  Did the exceptions all occur at the same time or did 
>the second and third exceptions occur after you restarted Seamonkey?
>

  All occurred at the same time.  I immediately stopped the dump facility
afterwards.

  Regards,

Dave McKenna



0
David
7/9/2011 3:24:54 PM
Steven Levine wrote:
>> >     http://hg.mozilla.org/releases/comm-2.0/
>> >     http://hg.mozilla.org/releases/mozilla-2.0/
> OK.  Since I already have a clone of
>
>    http://hg.mozilla.org/comm-central/
>
> can I do an hg update to switch to the sources that correspond to your
> build (minus patches of course).
>

You can edit your comm-central\.hg\hgrc to contain
default = http://hg.mozilla.org/releases/comm-2.0
and likewise with mozilla-central,
default = http://hg.mozilla.org/releases/mozilla-2.0
pull then update -r "correct revision" in both repositories.
Dave

0
Dave
7/9/2011 4:09:27 PM
On Sat, 9 Jul 2011 12:40:30 UTC, "Rich Walsh" <spamyourself@127.0.0.1>
wrote:

Hi Rich,

> This tag for m-c may not be available on the trunk but you can
> probably use the preceeding one:
> 
>   changeset:   63471:b4300fdb3f0e
>   branch:      COMM20_053111_RELBRANCH

OK.  I am still getting my head around the organization of the Mozilla
repositories.  For example I see Seamonkey tags I what I thought were 
Firefox/Thunderbird only repos.

The trap is indeed in TCPIP32, and elsewhere :-)

The files, David provided, sorted in timestamp order were

 7-08-11  15:52          24,266      0  00A1_13.TRP
 7-08-11  15:52     221,199,102      0  PDUMP.000
 7-08-11  15:52     219,979,620      0  PDUMP.001
 7-08-11  15:52     219,979,620      0  PDUMP.002
 7-08-11  15:52           1,206      0  POPUPLOG.OS2

What I think happened is that exceptq was the first to see the trap.  
Pdump.000 is the result of libc seeing the trap.  Pdump.001 and 
Pdump.002 are cascading traps.  I can see the exception report in pmdf
and it matches what the .trp file shows and I should have a stack 
backtrace in a while, now that I am back to work on this.  Acpi.psd 
got some priority this morning.

Steven

-- 
---------------------------------------------------------------------
Steven Levine <steve53@earthlink.bogus.net>
eCS/Warp/DIY etc. www.scoug.com www.ecomstation.com
---------------------------------------------------------------------
0
Steven
7/9/2011 10:54:28 PM
On Sat, 9 Jul 2011 16:09:27 UTC, Dave Yeo <dave.r.yeo@gmail.com> 
wrote:

Hi Dave,

> You can edit your comm-central\.hg\hgrc to contain
> default = http://hg.mozilla.org/releases/comm-2.0
> and likewise with mozilla-central,
> default = http://hg.mozilla.org/releases/mozilla-2.0
> pull then update -r "correct revision" in both repositories.

I know this, but why would I want to?  Are you saying that the 
existing comm-central and mozilla-central repositories are going to be
retired?

Steven

-- 
---------------------------------------------------------------------
Steven Levine <steve53@earthlink.bogus.net>
eCS/Warp/DIY etc. www.scoug.com www.ecomstation.com
---------------------------------------------------------------------
0
Steven
7/10/2011 12:05:47 AM
On Sat, 9 Jul 2011 15:24:54 UTC, "David McKenna" 
<davidmckenna@comcast.net> wrote:

Hi David,

>   All occurred at the same time.  I immediately stopped the dump facility
> afterwards.

Yes, I could see this once I had the zip file in hand.

Thanks,

Steven


-- 
---------------------------------------------------------------------
Steven Levine <steve53@earthlink.bogus.net>
eCS/Warp/DIY etc. www.scoug.com www.ecomstation.com
---------------------------------------------------------------------
0
Steven
7/10/2011 12:06:40 AM
Steven Levine wrote:
> On Sat, 9 Jul 2011 12:40:30 UTC, "Rich Walsh"<spamyourself@127.0.0.1>
> wrote:
>
> Hi Rich,
>
>> >  This tag for m-c may not be available on the trunk but you can
>> >  probably use the preceeding one:
>> >
>> >     changeset:   63471:b4300fdb3f0e
>> >     branch:      COMM20_053111_RELBRANCH
> OK.  I am still getting my head around the organization of the Mozilla
> repositories.  For example I see Seamonkey tags I what I thought were
> Firefox/Thunderbird only repos.

SeaMonkey and Thunderbird are based in comm-central and have a 
subdirectory called mozilla which is where Firefox lives in mozilla-central.
So SeaMonkey and Thunderbird use 2 repositories (actually more including 
things like IRC) and Firefox uses one which SeaMonkey and Thunderbird 
depend on.
Dave
0
Dave
7/10/2011 12:12:04 AM
Steven Levine wrote:
> On Sat, 9 Jul 2011 16:09:27 UTC, Dave Yeo<dave.r.yeo@gmail.com>
> wrote:
>
> Hi Dave,
>
>> >  You can edit your comm-central\.hg\hgrc to contain
>> >  default =http://hg.mozilla.org/releases/comm-2.0
>> >  and likewise with mozilla-central,
>> >  default =http://hg.mozilla.org/releases/mozilla-2.0
>> >  pull then update -r "correct revision" in both repositories.
> I know this, but why would I want to?  Are you saying that the
> existing comm-central and mozilla-central repositories are going to be
> retired?

Just a simple low bandwidth way to change from trunk to the 2.0 
repositories.
Dave
0
Dave
7/10/2011 12:27:36 AM
On Sat, 9 Jul 2011 22:54:28 UTC, "Steven Levine" 
<steve53@nomail.earthlink.net> wrote:

OK, we have some answers.  The nspr routine that triggered the trap 
was call to PR_GetHostByName to resolve "en.wikipedia.org", but I have
to believe it is only indirectly related to the trap itself.

The trap is in the tcpip32 runtime code that implements free() and it 
must be trapping because something has corrupted the heap.

My first recommendation is that Dave take a look at his HOSTS file.  
The free() call is the result of tcpip32 closing the HOSTS files.   I 
would check for very long lines or perhaps an extremely large hosts 
file.  If that's not it, will do some more analysis.

Steven




-- 
---------------------------------------------------------------------
Steven Levine <steve53@earthlink.bogus.net>
eCS/Warp/DIY etc. www.scoug.com www.ecomstation.com
---------------------------------------------------------------------
0
Steven
7/10/2011 8:52:45 AM
On 10.07.2011 10:52, Steven Levine wrote:
> My first recommendation is that Dave take a look at his HOSTS file.  
> The free() call is the result of tcpip32 closing the HOSTS files.   I 
> would check for very long lines or perhaps an extremely large hosts 
> file.  If that's not it, will do some more analysis.

Interesting, I always used the hosts file from http://www.mvps.org/winhelp2002/
when I was still using OS/2 (and getting these crashes) and that is quite large.
   Peter.
0
Peter
7/10/2011 12:47:17 PM
Steven,

On Sun, 10 Jul 2011 03:52:45 -0500, Steven Levine wrote:

>On Sat, 9 Jul 2011 22:54:28 UTC, "Steven Levine" 
><steve53@nomail.earthlink.net> wrote:
>
>OK, we have some answers.  The nspr routine that triggered the trap 
>was call to PR_GetHostByName to resolve "en.wikipedia.org", but I have
>to believe it is only indirectly related to the trap itself.
>
>The trap is in the tcpip32 runtime code that implements free() and it 
>must be trapping because something has corrupted the heap.
>
>My first recommendation is that Dave take a look at his HOSTS file.  
>The free() call is the result of tcpip32 closing the HOSTS files.   I 
>would check for very long lines or perhaps an extremely large hosts 
>file.  If that's not it, will do some more analysis.
>

  My HOSTS file only contains:

127.0.0.1             localhost                  # 

  There is no 'carriage return' after the #.

  I do use OS/2's firewall. I'll try running without it for a bit and see if
there is any effect.

Regards,

Dave McKenna



0
David
7/10/2011 1:35:46 PM
On Sun, 10 Jul 2011 09:35:46 -0400 (EDT), David McKenna wrote:

>Steven,
>
>On Sun, 10 Jul 2011 03:52:45 -0500, Steven Levine wrote:
>
>>On Sat, 9 Jul 2011 22:54:28 UTC, "Steven Levine" 
>><steve53@nomail.earthlink.net> wrote:
>>
>>OK, we have some answers.  The nspr routine that triggered the trap 
>>was call to PR_GetHostByName to resolve "en.wikipedia.org", but I have
>>to believe it is only indirectly related to the trap itself.
>>
>>The trap is in the tcpip32 runtime code that implements free() and it 
>>must be trapping because something has corrupted the heap.
>>
>>My first recommendation is that Dave take a look at his HOSTS file.  
>>The free() call is the result of tcpip32 closing the HOSTS files.   I 
>>would check for very long lines or perhaps an extremely large hosts 
>>file.  If that's not it, will do some more analysis.
>>
>
>  My HOSTS file only contains:
>
>127.0.0.1             localhost                  # 
>
>  There is no 'carriage return' after the #.
>
>  I do use OS/2's firewall. I'll try running without it for a bit and see if
>there is any effect.
>
>Regards,
>
>Dave McKenna

  Didn't take long... I already got a TCPIP32 crash with the firewall off....



0
David
7/10/2011 1:46:06 PM
Peter Weilbacher wrote:
> On 10.07.2011 10:52, Steven Levine wrote:
>> My first recommendation is that Dave take a look at his HOSTS file.
>> The free() call is the result of tcpip32 closing the HOSTS files.   I
>> would check for very long lines or perhaps an extremely large hosts
>> file.  If that's not it, will do some more analysis.
>
> Interesting, I always used the hosts file from http://www.mvps.org/winhelp2002/
> when I was still using OS/2 (and getting these crashes) and that is quite large.
>     Peter.

I'm using that hosts file, 620KB big, and have never had a crash in 
tcpip32.dll
Dave
0
Dave
7/10/2011 3:02:44 PM
On Sun, 10 Jul 2011 13:35:46 UTC, "David McKenna" 
<davidmckenna@comcast.net> wrote:

Hi David,

>   My HOSTS file only contains:
> 
> 127.0.0.1             localhost                  # 
> 
>   There is no 'carriage return' after the #.

I would add a blank line at the end of the file, just in case.  Lots 
of code does not deal well with missing line endings.

When did you last change this file?  Was it different before the traps
started to occur?

>   I do use OS/2's firewall. I'll try running without it for a bit and see if
> there is any effect.

It's not likely that this will have an effect.

When dealing with heap corruption, the cause of the corruption and the
what the code is doing at the time of the trap can be totally 
unrelated.  I mentioned the HOSTS file as a possible culprit only 
because this was the what tcpip32 was working on at the time.

FWIW, the free() that trapped was for a read buffer, but rather it was
for the data structure that contained the state of the file handle 
associated with the HOSTS file.

Another point for those reading along, is that the corrupted heap is 
not the Mozilla app's heap; it is tcpip32's heap.  This implies that 
the heap corruption was caused by some code in tcpip32.  However, it 
is also true that the corruption could be related to some data that 
the Mozilla apps that tcpip32.dll mishandled.

I need to see if I can recognize the data in memory that surrounds the
corrupted heap block.

Steven


-- 
---------------------------------------------------------------------
Steven Levine <steve53@earthlink.bogus.net>
eCS/Warp/DIY etc. www.scoug.com www.ecomstation.com
---------------------------------------------------------------------
0
Steven
7/10/2011 3:09:50 PM
Steven,

On Sun, 10 Jul 2011 10:09:50 -0500, Steven Levine wrote:

>On Sun, 10 Jul 2011 13:35:46 UTC, "David McKenna" 
><davidmckenna@comcast.net> wrote:
>
>Hi David,
>
>>   My HOSTS file only contains:
>> 
>> 127.0.0.1             localhost                  # 
>> 
>>   There is no 'carriage return' after the #.
>
>I would add a blank line at the end of the file, just in case.  Lots 
>of code does not deal well with missing line endings.
>
>When did you last change this file?  Was it different before the traps
>started to occur?
>

  I have never changed the HOSTS file since installing eCS 2.1.

  I also got these traps with eCS 2.0 pretty much since the beginning of
SeaMonkey 2.1 builds, if I remember correctly. I also never go for more than
about a half hour of browsing without getting one.

  I'll add the <return> to the HOSTS file and report if there is any
improvement, thanks.

Regards,

Dave McKenna



0
David
7/10/2011 3:22:36 PM
Steven,

On Sun, 10 Jul 2011 11:22:36 -0400 (EDT), David McKenna wrote:

>Steven,
>
>On Sun, 10 Jul 2011 10:09:50 -0500, Steven Levine wrote:
>
>>On Sun, 10 Jul 2011 13:35:46 UTC, "David McKenna" 
>><davidmckenna@comcast.net> wrote:
>>
>>Hi David,
>>
>>>   My HOSTS file only contains:
>>> 
>>> 127.0.0.1             localhost                  # 
>>> 
>>>   There is no 'carriage return' after the #.
>>
>>I would add a blank line at the end of the file, just in case.  Lots 
>>of code does not deal well with missing line endings.
>>
>>When did you last change this file?  Was it different before the traps
>>started to occur?
>>
>
>  I have never changed the HOSTS file since installing eCS 2.1.
>
>  I also got these traps with eCS 2.0 pretty much since the beginning of
>SeaMonkey 2.1 builds, if I remember correctly. I also never go for more than
>about a half hour of browsing without getting one.
>
>  I'll add the <return> to the HOSTS file and report if there is any
>improvement, thanks.
>

  This doesn't 'prove' anything but I'll toss it out there...

  I noticed today in my BIOS that Hyperthreading was turned on (this rig has
an i3 processor). When I first got this motherboard I had tried turning it on
and off and noticed when turned on WPS performance was better, so I left it
on. The docs for ACPI on eCS 2.1also imply that it works with Hyperthreading
even though in the past they recommended turning it off.

  I decided to try turning HT off. After that I was able to use SeaMonkey for
about 1.5 hours and did not get one single TCPIP32 crash - a record! I turned
HT back on and within 5 minutes I had a TCPIP32 crash.

  I will leave HT off and see how long (or if) it takes to get a TCPIP32
crash. I have not had any strange crashes with any other software with HT
turned on, so maybe this is a red herring?

  I wonder if anyone else getting these crashes has HT enabled (or not)?

Dave McKenna



0
David
7/10/2011 6:26:33 PM
Sir:

David McKenna wrote:
<snip>
>    This doesn't 'prove' anything but I'll toss it out there...
>
>    I noticed today in my BIOS that Hyperthreading was turned on (this rig has
> an i3 processor). When I first got this motherboard I had tried turning it on
> and off and noticed when turned on WPS performance was better, so I left it
> on. The docs for ACPI on eCS 2.1also imply that it works with Hyperthreading
> even though in the past they recommended turning it off.
>
>    I decided to try turning HT off. After that I was able to use SeaMonkey for
> about 1.5 hours and did not get one single TCPIP32 crash - a record! I turned
> HT back on and within 5 minutes I had a TCPIP32 crash.
>
>    I will leave HT off and see how long (or if) it takes to get a TCPIP32
> crash. I have not had any strange crashes with any other software with HT
> turned on, so maybe this is a red herring?
>
>    I wonder if anyone else getting these crashes has HT enabled (or not)?
>

I don't have an Intel processor, thus no hyperthreading.  I get these 
traps often.
-- 
Bill
Thanks a Million!
0
William
7/10/2011 7:42:47 PM
On Sun, 10 Jul 2011 10:09:50 -0500, Steven Levine
<steve53@nomail.earthlink.net> wrote:

>> 127.0.0.1             localhost                  # 
>> 
>>   There is no 'carriage return' after the #.
> 
> I would add a blank line at the end of the file, just in case.  Lots 
> of code does not deal well with missing line endings.

A single CR-LF at the end of a file does NOT constitute a blank line.
A double CR-LF would though.

Why do some people refuse to press Enter at the end of a line to
terminate it? It irritates the hell out of me when I press Ctrl-End to
go to the bottom and start typing and find it appears somewhere other
than column 1.
0
Paul
7/10/2011 10:22:05 PM
Steve Wendt wrote:
> On 7/4/2011 6:11 PM, Rich Walsh wrote:
>
>>>> Full-featured native printing support in Firefox and Seamonkey is now
>>>> available for testing.
>>>
>>> Is it fully functional for mail/news now, or does that still require
>>> using print preview?
>>
>> You have to use print preview. Is this an issue on other platforms?
>
> Not that I am aware of.
I am typing this on Linux SM 2.14.  No problems with printing of any 
kind that I have noticed.  And, AFAIK, there has been no update to this 
system in several weeks.  Printing has always worked without issues.

This is why I've been so frustrated with SM on eCS.  Printing is such a 
basic function.  I've never understood how the package could have ever 
been considered for release without printing working.

Just for the record, my Linux is:  Ubuntu Mint 8.  The system has all 
updates that are automatically supplied by the standard update process.

0
MCGJr
7/10/2011 11:41:33 PM
MCGJr wrote:
>
> This is why I've been so frustrated with SM on eCS.  Printing is such a
> basic function.  I've never understood how the package could have ever
> been considered for release without printing working.

It was a choice between having a working browser that didn't correctly 
print or no browser. Most people would rather have a non-printing modern 
browser then a printing browser that can't display most pages and 
therefore can't print them anyways.
The choice to use an older browser that prints has not been taken away 
from you.
Dave
0
Dave
7/11/2011 2:19:18 AM
Dave Yeo wrote:
> MCGJr wrote:
>>
>> This is why I've been so frustrated with SM on eCS. Printing is such a
>> basic function. I've never understood how the package could have ever
>> been considered for release without printing working.
>
> It was a choice between having a working browser that didn't correctly
> print or no browser. Most people would rather have a non-printing modern
> browser then a printing browser that can't display most pages and
> therefore can't print them anyways.
> The choice to use an older browser that prints has not been taken away
> from you.
> Dave
Sorry if I hit a nerve.  But, I understand that option and that's where 
I am.  I do a LOT of printing to PDFs that must be text-searchable 
[sic].  I guess I'll be stuck here until someone figures out how to 
handle this basic requirement or I am forced to move off of eCS because 
it is no longer viable.

Just one more problem to add to the list!

BTW, I am having to access this NG from Linux, because most attempts to 
do so from eCS crash SM [at best] and the entire system [at worse]. 
Maybe it is not all SM that's causing the problem.  Maybe it is an eCS 
issue.  But, things were working quite well for many months and all of a 
sudden, things are breaking right and left.  And, at least in the case 
of SM, I cannot move if I cannot do my job because of a basic function 
like printing that does not work without a lot of jury-rigging extra work.

PLEASE understand!  I am not directing this as a personal attack on you 
[especially] or on any other individual.  I DO appreciate the volunteer 
work that you all do.  But, eCS and its related components are not a 
hobby for me.  My system is a tool to do my work.  And, if the tool is 
broken, the work suffers.
0
MCGJr
7/12/2011 4:49:52 PM
On 7/12/2011 9:49 AM, MCGJr wrote:

> BTW, I am having to access this NG from Linux, because most attempts to
> do so from eCS crash SM [at best] and the entire system [at worse].

Have you tried with a new profile?  I've not seen anyone else report 
issues like this.
0
Steve
7/12/2011 5:11:06 PM
On Tue, 12 Jul 2011 16:49:52 UTC, MCGJr <carl.gehr.DeSpam@DeSpam.mcgcg.com> wrote:

> I do a LOT of printing to PDFs that must be text-searchable 

Is there some problem with the PDFs that the Mozilla apps produce that
make them unusable for you?  The text in the ones I just tried was
fully searchable and selectable.


-- 
== == almost usable email address:  Rich AT E-vertise DOT Com == ==

0
Rich
7/13/2011 1:20:10 AM
Sir:

Steven Levine wrote:
> On Fri, 8 Jul 2011 04:27:46 UTC, "Rich
> Walsh"<spamyourself@127.0.0.1> wrote:
>
> Hi Rich,
>
>> Absolutely!  Since Dave McKenna gets 8 of these crashes an hour,
>> perhaps he'd be willing to create a dump.  How about it, Dave?
>>
>> FWIW... my suspicion (as yet untested) in that we're passing a null
>> data buffer to some of the functions in
>> 'nsprpub\pr\src\md\os2\os2sock.c'.
>
> OK.  I'm am going to need the .map files for whatever build David is
> using.
>
> I'll also need the specs for the tag that the build was based on and
> a pointer to where any required patches live in case I need to look
> at the sources.
>
I was reading a new RFC last night that covered known problems with
TCPIP version 4 implementations.  While most of it did not concern us, 
it did mention that BSD 4.4 stack has built-in limits to the over-all 
size in bytes that can be allocated to buffers by the Tcpip stack for 
incoming packets and packet reassembly.  I was wondering if/since the 
newer Mozillas were using multiple threads of connectivity and we might 
be running out of space?  In other words how well are we checking the 
return size of buffers allocated and if TCPIP32.dll might be rejecting 
the use of these buffers, since OS/2 Tcpip is BSD 4.4?  I looked to see 
if this (buffer in-queue maximum size) was configurable and it is not.

-- 
Bill
Thanks a Million!
0
William
7/15/2011 10:23:40 PM
Sir:

William L. Hartzell wrote:
> Sir:
>
> Steven Levine wrote:
>> On Fri, 8 Jul 2011 04:27:46 UTC, "Rich
>> Walsh"<spamyourself@127.0.0.1> wrote:
>>
>> Hi Rich,
>>
>>> Absolutely! Since Dave McKenna gets 8 of these crashes an hour,
>>> perhaps he'd be willing to create a dump. How about it, Dave?
>>>
>>> FWIW... my suspicion (as yet untested) in that we're passing a null
>>> data buffer to some of the functions in
>>> 'nsprpub\pr\src\md\os2\os2sock.c'.
>>
>> OK. I'm am going to need the .map files for whatever build David is
>> using.
>>
>> I'll also need the specs for the tag that the build was based on and
>> a pointer to where any required patches live in case I need to look
>> at the sources.
>>
> I was reading a new RFC last night that covered known problems with
> TCPIP version 4 implementations. While most of it did not concern us, it
> did mention that BSD 4.4 stack has built-in limits to the over-all size
> in bytes that can be allocated to buffers by the Tcpip stack for
> incoming packets and packet reassembly. I was wondering if/since the
> newer Mozillas were using multiple threads of connectivity and we might
> be running out of space? In other words how well are we checking the
> return size of buffers allocated and if TCPIP32.dll might be rejecting
> the use of these buffers, since OS/2 Tcpip is BSD 4.4? I looked to see
> if this (buffer in-queue maximum size) was configurable and it is not.
>
In limited test of this, I set via about:config all connections values 
to 4 to see if this might be a work-around of this problem.  So far over 
six hours without a crash.  Could so of you others that have this 
problem try this?
-- 
Bill
Thanks a Million!
0
William
7/16/2011 7:16:20 AM
Bill,

On Sat, 16 Jul 2011 02:16:20 -0500, William L. Hartzell wrote:

-snip-

>> I was reading a new RFC last night that covered known problems with
>> TCPIP version 4 implementations. While most of it did not concern us, it
>> did mention that BSD 4.4 stack has built-in limits to the over-all size
>> in bytes that can be allocated to buffers by the Tcpip stack for
>> incoming packets and packet reassembly. I was wondering if/since the
>> newer Mozillas were using multiple threads of connectivity and we might
>> be running out of space? In other words how well are we checking the
>> return size of buffers allocated and if TCPIP32.dll might be rejecting
>> the use of these buffers, since OS/2 Tcpip is BSD 4.4? I looked to see
>> if this (buffer in-queue maximum size) was configurable and it is not.
>>
>In limited test of this, I set via about:config all connections values 
>to 4 to see if this might be a work-around of this problem.  So far over 
>six hours without a crash.  Could so of you others that have this 
>problem try this?
>-- 

   I've been running for about a week now with Hyperthreading turned off and
have only got one TCPIP32 crash the whole time. I turned it back on this
morning and got one within two minutes.

   Leaving it on, I tried your suggestion about setting 'connections' values
to 4. I've been browsing that way (Rich's latest SeaMonkey) for 2 hours now
and have only got one TCPIP32 crash, so this does look like a good
workaround... thanks!

  I'm curious... why 4? Is there any reason to experiment with other values?

Regards,

Dave McKenna



0
David
7/16/2011 4:13:58 PM
Sir:

David McKenna wrote:
> Bill,
>
> On Sat, 16 Jul 2011 02:16:20 -0500, William L. Hartzell wrote:
>
> -snip-
>
>>> I was reading a new RFC last night that covered known problems with
>>> TCPIP version 4 implementations. While most of it did not concern us, it
>>> did mention that BSD 4.4 stack has built-in limits to the over-all size
>>> in bytes that can be allocated to buffers by the Tcpip stack for
>>> incoming packets and packet reassembly. I was wondering if/since the
>>> newer Mozillas were using multiple threads of connectivity and we might
>>> be running out of space? In other words how well are we checking the
>>> return size of buffers allocated and if TCPIP32.dll might be rejecting
>>> the use of these buffers, since OS/2 Tcpip is BSD 4.4? I looked to see
>>> if this (buffer in-queue maximum size) was configurable and it is not.
>>>
>> In limited test of this, I set via about:config all connections values
>> to 4 to see if this might be a work-around of this problem.  So far over
>> six hours without a crash.  Could so of you others that have this
>> problem try this?
>> --
>
>     I've been running for about a week now with Hyperthreading turned off and
> have only got one TCPIP32 crash the whole time. I turned it back on this
> morning and got one within two minutes.
>
>     Leaving it on, I tried your suggestion about setting 'connections' values
> to 4. I've been browsing that way (Rich's latest SeaMonkey) for 2 hours now
> and have only got one TCPIP32 crash, so this does look like a good
> workaround... thanks!
>
>    I'm curious... why 4? Is there any reason to experiment with other values?
>

BSD 4.4 Tcpip stack has certain problems that were fixed after the last 
time OS/2 version was synchronized with it.  The main one of these was 
related to exhaustion of resources that are associated to the input 
queue to the IP layer.  OS/2 version was synchronized in April of 1999 
and this bug was fixed on the BSD stack in August 2002.

The problem can be described as follows:
Facts:  BSD 4.4 in April 1999 allocated 4 MiB of in-queue space.  It 
sub-allocated space within this to incoming packets, whatever size the 
un-fragmented packet says it size to be.  However, for each unknown 
fragmented packet the stack sub-allocated 32 KiB of space.  The stack 
also had a policy of clearing out half of all unfinished assembly of 
fragmented packets when the free space in the queue became less than one 
third free.  This is to prevent un-fragmented packets from being dropped 
because of lack of space, and yes, the in-queue handled both.
Facts: There are two principal sizes that TCPIP VERSION 4 packets that 
can be found: Ethernet size of about 1500 bytes, or Token Ring size of 8 
KiB.  Ethernet size using protocols include: dial up, Ethernet (802.3), 
WiFi (802.11), Cell Phones (802.17), and DSL over Ethernet.  Token Ring 
size using protocols are Token Ring (802.5), FIDI, MAN (802.6), ATM, 
Frame Relay, DSL over ATM, & DSL over Frame Relay.  The Link layer 
frames are sized to fit one of these.  IP packet are fitted into these 
frames.  Token Ring packets are almost always sent with the May Fragment 
flag enabled.
The Problem is two fold:  If the server is a machine on a Token Ring 
using protocol, like a machine using Frame Relay to connect to its ISP, 
then it will be sending out packets of 8 KiB size.  IF somewhere between 
there and another domain exist a router that is using Ethernet protocol, 
then the packet will be fragmented.  The usual rule is to fragment the 
packet into whatever size packet that a whole number will divide that 
original packet into without there being a remainder, plus one (N+1). 
So the Token Ring packet will be divided into seven packets and a GRE 
header & trailer are slapped onto each the divided packets.  These 
sub-divided packets are all related by a common sequence number, so that 
they can be reassembled.  Only the first GRE packet contains the 
original header which says what size the reassembled packet will be.
The other problem is with the Linux TCPIP stack.  When it fragments a 
packet, it always sends out the last GRE packet first and the first GRE 
packet last, ie back-ass-ward.  So if there is no mixing of the order, 
the end host will get the last packet first and not know the size of the 
finished packet and allocate what it think is reasonable size to hold 
it: in our BDS 4.4 case it is 32 KiB.  (BTW, that has been changed to 9 
KiB in 2004.)

So our problem is before hand we establish a wide receiver window of 
eight TCP Segments (TCP segments are equal to IP packet plug header and 
trailer of about 48 bytes.), because we have a reasonable fast 
connection.  The we go to a web site that is connected via Token Ring 
technology.  And then we get packets from there that are fragmented by a 
in-route router using Linux stack, and boom we got 7 times 8 packets in 
transit along with the need to re-assemble them.  Multiple that by 30 
connections, which this the number of connections that Mozilla will 
attempt to use.  Then multiple that time 32 KiB per each, and very 
quickly you run out of space in the queue.  This is one reason that when 
loading a page, you get that 30 to 120 second hang.  That is how long it 
takes for the OS/2 TCPIP stack to realize that it has lost packets and 
slam close the large receiver window to one packet.  Our version of BSD 
stack has a bug in that there exist a race condition between the space 
clearing routine (for too full input queue) and the transfer of 
completed reassembled packet to TCP layer.  The pointer to the 
transferred packet gets deleted and we have a null pointer on the stack. 
  Crash time.

I was hoping that by limiting the number of connections up-front, that 
we would avoid this bug.  The only other suggestion is to limit the size 
of the TCP receiver window to half the default, which is not easy as 
that value is dynamic.

The value of four was pulled out of my hat.  My reasoning was that a 
slow connection (dial-up) could not use more than four without problems 
and a very fast connection (10 Mib/s to 100 Mib/s) that small a number 
would not matter.  The only ones that would benefit by higher number 
would be those on DSL.  I expect that over ten connections would trigger 
the bug just as would 30.

PS. I am not saying that IBM did not fix these bugs, but it would seem 
unlikely.  But if they did fix these bugs, then there is a problem in 
Mozilla.

BTW, did you re-start Mozilla after you change the connections numbers? 
  May need to do so.
-- 
Bill
Thanks a Million!
0
William
7/16/2011 8:44:40 PM
Bill,

 16 Jul 2011 15:44:40 -0500, William L. Hartzell wrote:

>Sir:
-snip-
>
>BSD 4.4 Tcpip stack has certain problems that were fixed after the last 
>time OS/2 version was synchronized with it.  The main one of these was 
>related to exhaustion of resources that are associated to the input 
>queue to the IP layer.  OS/2 version was synchronized in April of 1999 
>and this bug was fixed on the BSD stack in August 2002.
>
>The problem can be described as follows:
>Facts:  BSD 4.4 in April 1999 allocated 4 MiB of in-queue space.  It 
>sub-allocated space within this to incoming packets, whatever size the 
>un-fragmented packet says it size to be.  However, for each unknown 
>fragmented packet the stack sub-allocated 32 KiB of space.  The stack 
>also had a policy of clearing out half of all unfinished assembly of 
>fragmented packets when the free space in the queue became less than one 
>third free.  This is to prevent un-fragmented packets from being dropped 
>because of lack of space, and yes, the in-queue handled both.
>Facts: There are two principal sizes that TCPIP VERSION 4 packets that 
>can be found: Ethernet size of about 1500 bytes, or Token Ring size of 8 
>KiB.  Ethernet size using protocols include: dial up, Ethernet (802.3), 
>WiFi (802.11), Cell Phones (802.17), and DSL over Ethernet.  Token Ring 
>size using protocols are Token Ring (802.5), FIDI, MAN (802.6), ATM, 
>Frame Relay, DSL over ATM, & DSL over Frame Relay.  The Link layer 
>frames are sized to fit one of these.  IP packet are fitted into these 
>frames.  Token Ring packets are almost always sent with the May Fragment 
>flag enabled.
>The Problem is two fold:  If the server is a machine on a Token Ring 
>using protocol, like a machine using Frame Relay to connect to its ISP, 
>then it will be sending out packets of 8 KiB size.  IF somewhere between 
>there and another domain exist a router that is using Ethernet protocol, 
>then the packet will be fragmented.  The usual rule is to fragment the 
>packet into whatever size packet that a whole number will divide that 
>original packet into without there being a remainder, plus one (N+1). 
>So the Token Ring packet will be divided into seven packets and a GRE 
>header & trailer are slapped onto each the divided packets.  These 
>sub-divided packets are all related by a common sequence number, so that 
>they can be reassembled.  Only the first GRE packet contains the 
>original header which says what size the reassembled packet will be.
>The other problem is with the Linux TCPIP stack.  When it fragments a 
>packet, it always sends out the last GRE packet first and the first GRE 
>packet last, ie back-ass-ward.  So if there is no mixing of the order, 
>the end host will get the last packet first and not know the size of the 
>finished packet and allocate what it think is reasonable size to hold 
>it: in our BDS 4.4 case it is 32 KiB.  (BTW, that has been changed to 9 
>KiB in 2004.)
>
>So our problem is before hand we establish a wide receiver window of 
>eight TCP Segments (TCP segments are equal to IP packet plug header and 
>trailer of about 48 bytes.), because we have a reasonable fast 
>connection.  The we go to a web site that is connected via Token Ring 
>technology.  And then we get packets from there that are fragmented by a 
>in-route router using Linux stack, and boom we got 7 times 8 packets in 
>transit along with the need to re-assemble them.  Multiple that by 30 
>connections, which this the number of connections that Mozilla will 
>attempt to use.  Then multiple that time 32 KiB per each, and very 
>quickly you run out of space in the queue.  This is one reason that when 
>loading a page, you get that 30 to 120 second hang.  That is how long it 
>takes for the OS/2 TCPIP stack to realize that it has lost packets and 
>slam close the large receiver window to one packet.  Our version of BSD 
>stack has a bug in that there exist a race condition between the space 
>clearing routine (for too full input queue) and the transfer of 
>completed reassembled packet to TCP layer.  The pointer to the 
>transferred packet gets deleted and we have a null pointer on the stack. 
>  Crash time.
>
>I was hoping that by limiting the number of connections up-front, that 
>we would avoid this bug.  The only other suggestion is to limit the size 
>of the TCP receiver window to half the default, which is not easy as 
>that value is dynamic.
>
>The value of four was pulled out of my hat.  My reasoning was that a 
>slow connection (dial-up) could not use more than four without problems 
>and a very fast connection (10 Mib/s to 100 Mib/s) that small a number 
>would not matter.  The only ones that would benefit by higher number 
>would be those on DSL.  I expect that over ten connections would trigger 
>the bug just as would 30.
>
>PS. I am not saying that IBM did not fix these bugs, but it would seem 
>unlikely.  But if they did fix these bugs, then there is a problem in 
>Mozilla.
>
>BTW, did you re-start Mozilla after you change the connections numbers? 
>  May need to do so.
>-- 

  Thanks for the explanation! If I understand correctly, the problem will
only show up with a website on a server using a Token Ring protocol, and
especially running on Linux? Is there a way to determine this in advance?

  I did re-start SeaMonkey after making the changes you recommended. There is
no question this change has minimized the TCPIP32 crash occurrances (but not
eliminated them). The effect is similar to turning off Hyperthreading on this
hardware.

Regards,

Dave McKenna



0
David
7/16/2011 9:56:11 PM
Sir:

David McKenna wrote:
<snip>
>    Thanks for the explanation! If I understand correctly, the problem will
> only show up with a website on a server using a Token Ring protocol, and
> especially running on Linux? Is there a way to determine this in advance?
>
>    I did re-start SeaMonkey after making the changes you recommended. There is
> no question this change has minimized the TCPIP32 crash occurrances (but not
> eliminated them). The effect is similar to turning off Hyperthreading on this
> hardware.
>

There is no way to know beforehand, so don't bother.  Why not try 
turning hyperthreading off in addition to this?
-- 
Bill
Thanks a Million!
0
William
7/16/2011 11:27:46 PM
Bill,

On Sat, 16 Jul 2011 18:27:46 -0500, William L. Hartzell wrote:

>Sir:
>
>David McKenna wrote:
><snip>
>>    Thanks for the explanation! If I understand correctly, the problem will
>> only show up with a website on a server using a Token Ring protocol, and
>> especially running on Linux? Is there a way to determine this in advance?
>>
>>    I did re-start SeaMonkey after making the changes you recommended. There is
>> no question this change has minimized the TCPIP32 crash occurrances (but not
>> eliminated them). The effect is similar to turning off Hyperthreading on this
>> hardware.
>>
>
>There is no way to know beforehand, so don't bother.  Why not try 
>turning hyperthreading off in addition to this?
>-- 

  Yes, I will probably do this eventually but I get a noticable performance
improvement with HT left on with everything except SeaMonkey so I would
prefer not to if I can get away with it. Time will tell...

Regards,

Dave McKenna



0
David
7/17/2011 2:55:28 AM
David McKenna wrote: > Bill, > > On Sat, 16 Jul 2011 18:27:46 -0500, 
William L. Hartzell wrote: > >> Sir: >> >> David McKenna wrote: >> 
<snip> >>>     Thanks for the explanation! If I understand correctly, 
the problem will >>> only show up with a website on a server using a 
Token Ring protocol, and >>> especially running on Linux? Is there a way 
to determine this in advance? >>> >>>     I did re-start SeaMonkey after 
making the changes you recommended. There is >>> no question this change 
has minimized the TCPIP32 crash occurrances (but not >>> eliminated 
them). The effect is similar to turning off Hyperthreading on this >>> 
hardware. >>> >> >> There is no way to know beforehand, so don't bother. 
  Why not try >> turning hyperthreading off in addition to this? >> -- > 
 >    Yes, I will probably do this eventually but I get a noticable 
performance > improvement with HT left on with everything except 
SeaMonkey so I would > prefer not to if I can get away with it. Time 
will tell... >
How are you connected to the Internet? Including router?
I'll note that with my crappy dial-up connection I've never had a crash 
in TCPIP32.DLL

Dave
0
Dave
7/17/2011 3:40:41 AM
Dave,

On Sat, 16 Jul 2011 20:40:41 -0700, Dave Yeo wrote:

>David McKenna wrote: > Bill, > > On Sat, 16 Jul 2011 18:27:46 -0500, 
>William L. Hartzell wrote: > >> Sir: >> >> David McKenna wrote: >> 
><snip> >>>     Thanks for the explanation! If I understand correctly, 
>the problem will >>> only show up with a website on a server using a 
>Token Ring protocol, and >>> especially running on Linux? Is there a way 
>to determine this in advance? >>> >>>     I did re-start SeaMonkey after 
>making the changes you recommended. There is >>> no question this change 
>has minimized the TCPIP32 crash occurrances (but not >>> eliminated 
>them). The effect is similar to turning off Hyperthreading on this >>> 
>hardware. >>> >> >> There is no way to know beforehand, so don't bother. 
>  Why not try >> turning hyperthreading off in addition to this? >> -- > 
> >    Yes, I will probably do this eventually but I get a noticable 
>performance > improvement with HT left on with everything except 
>SeaMonkey so I would > prefer not to if I can get away with it. Time 
>will tell... >
>How are you connected to the Internet? Including router?
>I'll note that with my crappy dial-up connection I've never had a crash 
>in TCPIP32.DLL
>

  My computer is wired to a Gigabit switch that is wired to a LinkSys router
(which includes wireless capability) running DD-WRT firmware that is wired to
a COMCAST Arris TM722 cable box.

  One of these days I'll probably switch to Verizon FIOS....

Regards,

Dave McKenna



0
David
7/17/2011 4:13:10 AM
Sir:

David McKenna wrote:
<snip>
>> How are you connected to the Internet? Including router?
>> I'll note that with my crappy dial-up connection I've never had a crash
>> in TCPIP32.DLL
>>
>
>    My computer is wired to a Gigabit switch that is wired to a LinkSys router
> (which includes wireless capability) running DD-WRT firmware that is wired to
> a COMCAST Arris TM722 cable box.
>
>    One of these days I'll probably switch to Verizon FIOS....
>

I wish I could switch over to Version FIOS.  Version has the cable run 
down the alley. But since I am in an apartment, they don't have 
permission to run service to the unit in which I am residing.

As to the first time I ran into the this bug was when I started using 
this SMP machine.  The US CERT says that they, the first users, ran into 
this bug in January of 2002, but not on OS/2.

Dave, it might speed up your download of web sites if you did lower your 
number of connections.  You would get fewer different incomplete 
fragments and the time-out on re-assembling them.
-- 
Bill
Thanks a Million!
0
William
7/17/2011 10:55:51 PM
On Sun, 17 Jul 2011 22:55:51 UTC, "William L. Hartzell" <wlhartzell@tx.rr.com> wrote:

> As to the first time I ran into the this bug was when I started using 
> this SMP machine.

With one exception, all of the trap reports I've received for this bug
have been from SMP machines.

BTW... since I started using the afinetk.sys dated 2007/06/05, I haven't
had a single crash (I used to get one or two per day).


-- 
== == almost usable email address:  Rich AT E-vertise DOT Com == ==

0
Rich
7/18/2011 12:21:31 PM
Hello Rich and everyone else,

I've done some testing with the 201107 build of SeaMonkey 2.1 that enables 
printing. The issues I have with printing under Mozilla are cross-platform (I 
always check against the Windows version), so I'd say the OS/2 version works 
now at the same quality level of the WinXP version. My testing is limited, 
though, so this could be an adventurous comment. Now, let's address PDF printing.

The ability to directly produce PDF output is a very nice feature of the OS2 
port of Mozilla, which AFAICT is not present in the Windows version (is it? 
where/how?). I gather this was introduced as a workaround for 'real printing' 
issues, but I'd like it not to be removed from the OS2 port. Just in case it 
counts somewhere.

The one issue I had with PDF generation before this build was that PDF output 
wasn't accurate wrt to the print preview; it always had a smaller line height 
or something, so if the preview said 10 full pages you got 9 and a half, etc. 
and it was cumulative, i.e. the longer the text the bigger the discrepancies. 
It showed especially when using A5 and other small paper sizes. I never got to 
pinpoint exactly what went wrong but these differences are gone now, so print 
preview mostly behaves as WYSIWYG. If others noticed this, maybe it should be 
kept in mind to prevent future regressions.

The other thing I noticed, and it's still there, is that paper orientation 
isn't respected when generating PDFs, and 'portrait' is always used. This is 
only a pain if you prepare something to be printed specifically in landscape, 
but it's there. With real printing back in game this is no longer an issue, 
since I can generate a landscape oriented PS file and convert it to PDF later, 
but still...

Everything else works for me, so it's the other bug finders' go now.

So, Rich, congratulations on a job well done! We owe you a lot :)
0
ISO
7/18/2011 5:58:12 PM
On 7/18/2011 10:58 AM, Alfredo Fern�ndez D�az wrote:

> The ability to directly produce PDF output is a very nice feature of the
> OS2 port of Mozilla, which AFAICT is not present in the Windows version
> (is it? where/how?).

There is a "print to file" option in the print dialog.  As I understand 
it, if you specify a PDF extension, you get PDF output.
0
Steve
7/18/2011 6:14:46 PM
On Mon, 18 Jul 2011 12:21:31 UTC, "Rich Walsh" 
<spamyourself@127.0.0.1> wrote:

> On Sun, 17 Jul 2011 22:55:51 UTC, "William L. Hartzell" <wlhartzell@tx.rr.com> wrote:
> 
> > As to the first time I ran into the this bug was when I started using 
> > this SMP machine.
> 
> With one exception, all of the trap reports I've received for this bug
> have been from SMP machines.
> 
> BTW... since I started using the afinetk.sys dated 2007/06/05, I haven't
> had a single crash (I used to get one or two per day).

So where does one get this version? The eCS 2.1 GA CD installs:

9-20-05  20:24         318,976      0  AFINETK.SYS
 
Thanks! 


-- 
Tom Brown, Catherder
thomabrown at gmail dot com
Member SCOUG & V.O.I.C.E.
0
Tom
7/18/2011 6:51:53 PM
Hi

Tom Brown wrote:
> On Mon, 18 Jul 2011 12:21:31 UTC, "Rich Walsh"
> <spamyourself@127.0.0.1>  wrote:
>
>> On Sun, 17 Jul 2011 22:55:51 UTC, "William L. Hartzell"<wlhartzell@tx.rr.com>  wrote:
>>
>>> As to the first time I ran into the this bug was when I started using
>>> this SMP machine.
>>
>> With one exception, all of the trap reports I've received for this bug
>> have been from SMP machines.
>>
>> BTW... since I started using the afinetk.sys dated 2007/06/05, I haven't
>> had a single crash (I used to get one or two per day).
>
> So where does one get this version? The eCS 2.1 GA CD installs:
>
> 9-20-05  20:24         318,976      0  AFINETK.SYS
>
>


Which seems to work fairly well; no instances of Seamonkey crashing due 
to tcpip32.dll problems (so far :-) on my eCS2.0 system, using SMP, 
since installing eCS2.0 on 29/05/2010.

Regards

Pete


0
Peter
7/18/2011 8:55:12 PM
Peter Brown wrote:
> Hi
>
> Tom Brown wrote:
>> On Mon, 18 Jul 2011 12:21:31 UTC, "Rich Walsh"
>> <spamyourself@127.0.0.1> wrote:
>>
>>> On Sun, 17 Jul 2011 22:55:51 UTC, "William L.
>>> Hartzell"<wlhartzell@tx.rr.com> wrote:
>>>
>>>> As to the first time I ran into the this bug was when I started using
>>>> this SMP machine.
>>>
>>> With one exception, all of the trap reports I've received for this bug
>>> have been from SMP machines.
>>>
>>> BTW... since I started using the afinetk.sys dated 2007/06/05, I haven't
>>> had a single crash (I used to get one or two per day).
>>
>> So where does one get this version?

I believe Rich is referring to 
http://www.os2site.com/sw/upgrades/tcpip/tcpip32_stack.zip
Dave
0
Dave
7/18/2011 10:21:40 PM
Sir:

Rich Walsh wrote:
> On Sun, 17 Jul 2011 22:55:51 UTC, "William L. Hartzell"<wlhartzell@tx.rr.com>  wrote:
>
>> As to the first time I ran into the this bug was when I started using
>> this SMP machine.
>
> With one exception, all of the trap reports I've received for this bug
> have been from SMP machines.
>
> BTW... since I started using the afinetk.sys dated 2007/06/05, I haven't
> had a single crash (I used to get one or two per day).
>
>

I'll give it a try as it is newer date than the one currently installed. 
  I wonder if IBM fixed the only other bug I've not mentioned in the BSD 
4.4 stack.  In the case of extremely fast connections, ie those over 
1000 Mib/s, that the sequence numbers would roll over mixing two or more 
fragments together?
BTW, the RFC is 6274 if any wish to check.
-- 
Bill
Thanks a Million!
0
William
7/18/2011 11:29:56 PM
On Mon, 18 Jul 2011 17:58:12 UTC, Alfredo Fern�ndez D�az wrote:

> The other thing I noticed, and it's still there, is that paper orientation 
> isn't respected when generating PDFs, and 'portrait' is always used. This is 
> only a pain if you prepare something to be printed specifically in landscape, 
> but it's there. With real printing back in game this is no longer an issue, 
> since I can generate a landscape oriented PS file and convert it to PDF later, 
> but still...

A Bugzilla patch (Bug 624699) was checked in a few days ago to get the built-in
PS printing to print in Landscape if requested - it will be in future releases.
The author of the patch seemed to think that all PDF viewers automatically
rotated the image if needed, so he didn't extend his fix to PDF.

In my tests with a PDF in Landscape mode, I found that the image remained in
portrait mode (i.e. not rotated) but the page was wider than it was long (as
it would be in Landscape).  For printing, Acrobat had an option to auto-rotate
and center the page as needed (which is what he said) but the image was
upside-down.  Lucide didn't have that option but did offer Landscape mode.
However the image was too small - as though it had been resized for Portrait.
Telling Lucide to rotate it, then printing in Portrait produced the expected
result.

Bottom line:  PDF output probably suits most people's needs, as-is, both
for viewing and printing.  The code to rotate the image to achieve true
Landscape output is trivial and could be copied from the PS patch.  However,
this is all cross-platform code which I can't change on my own.  If you
want to file a followup bug, do so - but don't mark it as OS/2-only because
it affects all platforms.



-- 
== == almost usable email address:  Rich AT E-vertise DOT Com == ==

0
Rich
7/19/2011 12:00:25 AM
On 7/18/2011 5:00 PM, Rich Walsh wrote:

> A Bugzilla patch (Bug 624699) was checked in a few days ago to get the built-in
> PS printing to print in Landscape if requested - it will be in future releases.

Note: "future release" at this point means Firefox 8 at the earliest, as 
6 is already in beta, and 7 already in alpha.
0
Steve
7/19/2011 1:03:33 AM
http://www.os2site.com/sw/upgrades/tcpip/tcpip32_stack.zip

Cheers
0
Ian
7/19/2011 7:55:00 AM
On Mon, 18 Jul 2011 18:03:33 -0700, Steve Wendt <spamsux@forgetit.org> wrote:

> Note: "future release" at this point means Firefox 8 at the earliest, as 
> 6 is already in beta, and 7 already in alpha.

Has somebody decided that Firefox needs version-itis then?
How ridiculous.
Presumably they are trying to beat IE in the numbers game for whatever
small minded reasons...
0
Paul
7/19/2011 5:54:24 PM
On 07/19/2011 01:54 PM, Paul Ratcliffe wrote:
> On Mon, 18 Jul 2011 18:03:33 -0700, Steve Wendt<spamsux@forgetit.org>  wrote:
>
>> Note: "future release" at this point means Firefox 8 at the earliest, as
>> 6 is already in beta, and 7 already in alpha.
>
> Has somebody decided that Firefox needs version-itis then?
> How ridiculous.
> Presumably they are trying to beat IE in the numbers game for whatever
> small minded reasons...

http://www.pcworld.com/article/231222/firefox_rapid_release_5_key_points.html

Bob Plyler
0
Bob
7/19/2011 6:07:23 PM
Steve Wendt escribi�:
> On 7/18/2011 10:58 AM, Alfredo Fern�ndez D�az wrote:
>
>> The ability to directly produce PDF output is a very nice feature of the
>> OS2 port of Mozilla, which AFAICT is not present in the Windows version
>> (is it? where/how?).
>
> There is a "print to file" option in the print dialog. As I understand it, if
> you specify a PDF extension, you get PDF output.

This is weird then...

I just tried it at home. WinXP, FX5 (silent update from 4) only a generic PS 
driver from Adobe is installed, no other PDF or PS tools installed at all, no 
about:config tweaks.

File -> Print -> Print as file -> xxx.pdf outputs a PostScript file.

OTOH, SeaMonkey 2.1 OS/2 (Rich's July 3rd build) outputs PDF regardless of 
the file being given an extension of PS or PDF when going through File -> 
Print -> Print as file when print.os2.postscript.use_builtin is FALSE.
You need it to be TRUE to get PS or PDF output according to the file extension.

The PDF file contents vary slightly, but output looks the same to human eyes.

So I would say PDF output is absent in the win32 Mozillas (or even maybe 
os2-specific), and it has some other glitches.

Rich?
0
ISO
7/19/2011 7:54:22 PM
Bob Plyler wrote:

> On 07/19/2011 01:54 PM, Paul Ratcliffe wrote:
>
>> Has somebody decided that Firefox needs version-itis then?

I see their Javascript blamage as a main reason for that.

>> How ridiculous.

Sure.

>> Presumably they are trying to beat IE in the numbers game for
>> whatever small minded reasons...

It would be time to move away from stuff like that, but there's no
opportunity.

> http://www.pcworld.com/article/231222/firefox_rapid_release_5_key_points.html

Requested cookies says it all: That's not my world.

-- 
Andreas Schnellbacher
0
Andreas
7/19/2011 10:09:58 PM
On Mon, 18 Jul 2011 12:21:31 UTC, "Rich Walsh" 
<spamyourself@127.0.0.1> wrote:

Hi Rich,

> With one exception, all of the trap reports I've received for this bug
> have been from SMP machines.
> 
> BTW... since I started using the afinetk.sys dated 2007/06/05, I haven't
> had a single crash (I used to get one or two per day).

What's the status of this?  I'm not quite sure how afinetk.sys could 
cause the tcpip32.dll runtime to do crash.  However, based on the trap
content, the issue could easily be SMP related.

It's a bit hard to see in the dump file David supplied, but the memory
content appears to have changed between the time of the exception and 
when the dump facility wrote out the memory content.

This could easily be a SMP sync issue.

Steven

-- 
---------------------------------------------------------------------
Steven Levine <steve53@earthlink.bogus.net>
eCS/Warp/DIY etc. www.scoug.com www.ecomstation.com
---------------------------------------------------------------------
0
Steven
7/19/2011 11:04:12 PM
On Tue, 19 Jul 2011 23:04:12 UTC, "Steven Levine" wrote:
> On Mon, 18 Jul 2011 12:21:31 UTC, "Rich Walsh" wrote:
> 
> > With one exception, all of the trap reports I've received for this bug
> > have been from SMP machines.
> > 
> > BTW... since I started using the afinetk.sys dated 2007/06/05, I haven't
> > had a single crash (I used to get one or two per day).
> 
> What's the status of this?  I'm not quite sure how afinetk.sys could 
> cause the tcpip32.dll runtime to do crash.

Magic, of course :-)  If there's a race condition (as Bill Hartzell reports),
then any change in the processing pipeline could affect which thread(?) gets
to the data first.

> However, based on the trap content, the issue could easily be SMP related.

I assume SMP would make race conditions more obvious.

> It's a bit hard to see in the dump file David supplied, but the memory
> content appears to have changed between the time of the exception and 
> when the dump facility wrote out the memory content.
> This could easily be a SMP sync issue.

I don't know if Dave's dump showed this, but I have several .trp files
where the report starts, gets part way through, then restarts with
different data.  It's as though a thread trapped and terminated, then
a new thread started with the same TID and also trapped.

If you'd like, I can send you some examples or I can send you the
login info for crashATe-vertise so you can look at all of them.



-- 
== == almost usable email address:  Rich AT E-vertise DOT Com == ==

0
Rich
7/19/2011 11:26:54 PM
On Tue, 19 Jul 2011 19:54:22 UTC, Alfredo Fern�ndez D�az wrote:

> I just tried it at home. WinXP, FX5 (silent update from 4) only a generic
> PS driver from Adobe is installed, no other PDF or PS tools installed at
> all, no about:config tweaks.
> 
> File -> Print -> Print as file -> xxx.pdf outputs a PostScript file.

The Win version is configured for PDF support but I don't know if it
is actually implemented.  If you selected a printer that uses a PS
driver, then getting PS output should not be a surprise.  AFAIK, only
OS/2 offers all these options.
 
> OTOH, SeaMonkey 2.1 OS/2 (Rich's July 3rd build) outputs PDF regardless
> of the file being given an extension of PS or PDF when going through
> File -> Print -> Print as file when print.os2.postscript.use_builtin
> is FALSE. You need it to be TRUE to get PS or PDF output according
> to the file extension.

This is a bug that I've fixed since that release.

In the next beta, you won't need the "use_builtin" option to create a
PS *file*.  If you choose a non-PS printer but give the file a ".ps"
extension, it will use the builtin generator.  OTOH, if you choose a
PS printer, it will create the file using that printer's native PS
driver.  Your choice...
 


-- 
== == almost usable email address:  Rich AT E-vertise DOT Com == ==

0
Rich
7/19/2011 11:53:57 PM
Steven,

On Tue, 19 Jul 2011 18:04:12 -0500, Steven Levine wrote:

>On Mon, 18 Jul 2011 12:21:31 UTC, "Rich Walsh" 
><spamyourself@127.0.0.1> wrote:
>
>Hi Rich,
>
>> With one exception, all of the trap reports I've received for this bug
>> have been from SMP machines.
>> 
>> BTW... since I started using the afinetk.sys dated 2007/06/05, I haven't
>> had a single crash (I used to get one or two per day).
>
>What's the status of this?  I'm not quite sure how afinetk.sys could 
>cause the tcpip32.dll runtime to do crash.  However, based on the trap
>content, the issue could easily be SMP related.
>
>It's a bit hard to see in the dump file David supplied, but the memory
>content appears to have changed between the time of the exception and 
>when the dump facility wrote out the memory content.
>
>This could easily be a SMP sync issue.
>

  FWIW... I was using the updated afinetk.sys (2007/06/05) when I created the
dump I sent you. Those files Ian mentioned did not help at all with the
TCPIP32 crashes here...

  If you want a new dump just say the word.

Regards,

Dave McKenna



0
David
7/20/2011 12:09:55 AM
On Tue, 19 Jul 2011 14:07:23 -0400, Bob Plyler <rplyler@us.nospam.ibm.com>
wrote:

>> Has somebody decided that Firefox needs version-itis then?
>> How ridiculous.
>> Presumably they are trying to beat IE in the numbers game for whatever
>> small minded reasons...
>
> http://www.pcworld.com/article/231222/firefox_rapid_release_5_key_points.html

What utter fucking stupidity. That'll probably kill it.
0
Paul
7/20/2011 12:12:42 AM
On Tue, 19 Jul 2011 23:26:54 UTC, "Rich Walsh" 
<spamyourself@127.0.0.1> wrote:

Hi,

> > What's the status of this?  I'm not quite sure how afinetk.sys could 
> > cause the tcpip32.dll runtime to do crash.
 
> Magic, of course :-)

Works for me.

> If there's a race condition (as Bill Hartzell reports),
> then any change in the processing pipeline could affect which thread(?) gets
> to the data first.

True enough.

> I assume SMP would make race conditions more obvious.

Always.

> I don't know if Dave's dump showed this, but I have several .trp files
> where the report starts, gets part way through, then restarts with
> different data.

Not directly.  What I got from Dave was a clean .trp file and 3 dump 
files.  The first dump file was related to the .trp file in the sense 
that I could find the exception report on the stack, but the dump was 
initiated by libc.  The other two dump files appeared to be cascading 
failures.

> It's as though a thread trapped and terminated, then
> a new thread started with the same TID and also trapped.

That is odd.  It makes me wonder if the semantics of the exception 
recursion prevention logic changed unintentionally.  The code looks 
OK, but this discussion makes me wonder if we are overlooking 
something and cTrapCount needs a bit more SMP protection.

Of course it's entirely possible for the same TID to trap multiple 
times, but exceptq is supposed to detect and report this.

> If you'd like, I can send you some examples or I can send you the
> login info for crashATe-vertise so you can look at all of them.

Either way works for me.  Perhaps, I will be able to explain what is 
happening.

Steven


-- 
---------------------------------------------------------------------
Steven Levine <steve53@earthlink.bogus.net>
eCS/Warp/DIY etc. www.scoug.com www.ecomstation.com
---------------------------------------------------------------------
0
Steven
7/20/2011 12:24:16 AM
Paul Ratcliffe wrote:
> On Mon, 18 Jul 2011 18:03:33 -0700, Steve Wendt<spamsux@forgetit.org>  wrote:
>
>> Note: "future release" at this point means Firefox 8 at the earliest, as
>> 6 is already in beta, and 7 already in alpha.
>
> Has somebody decided that Firefox needs version-itis then?
> How ridiculous.
> Presumably they are trying to beat IE in the numbers game for whatever
> small minded reasons...

Actually I think they're trying to beat chrome while copying hte worst 
features.
Dave
0
Dave
7/20/2011 1:18:33 AM
On Wed, 20 Jul 2011 00:09:55 UTC, "David McKenna" 
<davidmckenna@comcast.net> wrote:

Hi,

>   FWIW... I was using the updated afinetk.sys (2007/06/05) when I created the
> dump I sent you. Those files Ian mentioned did not help at all with the
> TCPIP32 crashes here...

OK.  I guess that's good to know. :-(

Is there any possibility that you have a RAM problem?  I don't think 
that this all that likely since you have indicated that the exceptions
are are consistently in the same tcpip32 DLL.  However, it can't hurt 
to give memtest86+ a try.  See

  http://www.memtest.org/

I find the bootable ISO's the easiet to use on eCS.

If the RAM checks out OK, I probably should look at another set of 
dump files, just to make sure the trap is consistent.

Steven


-- 
---------------------------------------------------------------------
Steven Levine <steve53@earthlink.bogus.net>
eCS/Warp/DIY etc. www.scoug.com www.ecomstation.com
---------------------------------------------------------------------
0
Steven
7/20/2011 6:24:47 AM
Steven Levine wrote:
> Is there any possibility that you have a RAM problem?  I don't think
> that this all that likely since you have indicated that the exceptions
> are are consistently in the same tcpip32 DLL.  However, it can't hurt
> to give memtest86+ a try

Not just memory, heat as well. I've been running FATE (ffmpeg automatic 
testing environment) for quite a while as video is also important to 
keeping OS/2 relevant. I started to fail the H264 conformance tests 
somewhat randomly. Took the computer apart, reseated the cards and blew 
out a big dust storm. I was passing all tests after this.
It's time to do this again as I've started failing the H264 tests once 
again. http://fate.libav.org, click on the x hours ago for recent 
history. libav is a fork of FFmpeg, they had a big revolt earlier this 
year ending in a fork and I seemed to end up with libav and the few OS/2 
specific patches I submitted ended in FFmpeg as well so all is well that 
way. Working MPlayer, VLC etc.
Dave
0
Dave
7/20/2011 6:48:28 AM
Rich Walsh wrote:
> On Tue, 19 Jul 2011 19:54:22 UTC, Alfredo Fern ndez D�az wrote:
>
>> I just tried it at home. WinXP...
>> File ->  Print ->  Print as file ->  xxx.pdf outputs a PostScript file.
>
> The Win version is configured for PDF support but I don't know if it
> is actually implemented.  If you selected a printer that uses a PS
> driver, then getting PS output should not be a surprise.

Of course, printing to file should get you a file that can be sent directly to 
printer, in whatever language it uses, unless the file name is somehow 
"special". The surprise wasn't getting postscript, but rather NOT getting PDF 
in analogy to OS/2, especially because the win version should be expected to 
be one of the most 'advanced' i.e. packed with features.

Not a problem for me, anyway. I've been fiddling with PS a lot lately, and 
it's much more useful for my purposes than PDF, to which I can always convert 
at a later stage.

> AFAIK, only OS/2 offers all these options.

:)

Would you mind submitting about landscape/portrait PDF at bugzilla yourself 
then? In the other sub-thread you said

"The code to rotate the image to achieve true Landscape output is trivial and 
could be copied from the PS patch. However, this is all cross-platform code 
which I can't change on my own. If you want to file a followup bug, do so - 
but don't mark it as OS/2-only because it affects all platforms."

and I don't have the slightest idea of what code belongs where, so I don't 
want to mess things up with inaccurate descriptions. Sorry for giving you 
extra work.

....
>> print.os2.postscript.use_builtin
>> You need it to be TRUE to get PS or PDF output according to the file
 >> extension.
>
> This is a bug that I've fixed since that release.

Superb! Keep up the good work.

> In the next beta, you won't need the "use_builtin" option to create a
> PS *file*.  If you choose a non-PS printer but give the file a ".ps"
> extension, it will use the builtin generator.  OTOH, if you choose a
> PS printer, it will create the file using that printer's native PS
> driver.  Your choice...

And a very logical one:

I assume -*please* correct me if I'm wrong here- you should get the exact same 
output file when you select File -> Print to file (with printer X selected), 
and when you print to printer X AND the printer's output port is set to 
'file', and that those file contents should be generated by printer X driver. 
So it would only make sense that to get output from some other device (the 
internal PS output engine) you should specify a special printer object or file 
name or whatever.

However, the fact that you mention this way is how "the next beta" works makes 
me guess it's not how it woks currently. Care to illustrate us if relevant?

Anyway, do you have an approximate schedule for the release of the next 
beta(s)? Will they be at the FX4/SM2.1 level, or will you go with higher 
versions as well?

Thanks again for the good work.
Regards,
0
ISO
7/20/2011 2:30:06 PM
On Sat, 16 Jul 2011 12:13:58 -0400 (EDT), David McKenna wrote:

>Bill,
>
>On Sat, 16 Jul 2011 02:16:20 -0500, William L. Hartzell wrote:
>
>-snip-
>
>>> I was reading a new RFC last night that covered known problems with
>>> TCPIP version 4 implementations. While most of it did not concern us, it
>>> did mention that BSD 4.4 stack has built-in limits to the over-all size
>>> in bytes that can be allocated to buffers by the Tcpip stack for
>>> incoming packets and packet reassembly. I was wondering if/since the
>>> newer Mozillas were using multiple threads of connectivity and we might
>>> be running out of space? In other words how well are we checking the
>>> return size of buffers allocated and if TCPIP32.dll might be rejecting
>>> the use of these buffers, since OS/2 Tcpip is BSD 4.4? I looked to see
>>> if this (buffer in-queue maximum size) was configurable and it is not.
>>>
>>In limited test of this, I set via about:config all connections values 
>>to 4 to see if this might be a work-around of this problem.  So far over 
>>six hours without a crash.  Could so of you others that have this 
>>problem try this?
>>-- 
>
>   I've been running for about a week now with Hyperthreading turned off and
>have only got one TCPIP32 crash the whole time. I turned it back on this
>morning and got one within two minutes.
>
>   Leaving it on, I tried your suggestion about setting 'connections' values
>to 4. I've been browsing that way (Rich's latest SeaMonkey) for 2 hours now
>and have only got one TCPIP32 crash, so this does look like a good
>workaround... thanks!
>
>  I'm curious... why 4? Is there any reason to experiment with other values?
>
>Regards,
>
>Dave McKenna




0
David
7/20/2011 9:55:46 PM
Hi Steven,

On Wed, 20 Jul 2011 01:24:47 -0500, Steven Levine wrote:

>On Wed, 20 Jul 2011 00:09:55 UTC, "David McKenna" 
><davidmckenna@comcast.net> wrote:
>
>Hi,
>
>>   FWIW... I was using the updated afinetk.sys (2007/06/05) when I created the
>> dump I sent you. Those files Ian mentioned did not help at all with the
>> TCPIP32 crashes here...
>
>OK.  I guess that's good to know. :-(
>
>Is there any possibility that you have a RAM problem?  I don't think 
>that this all that likely since you have indicated that the exceptions
>are are consistently in the same tcpip32 DLL.  However, it can't hurt 
>to give memtest86+ a try.  See
>
>  http://www.memtest.org/
>
>I find the bootable ISO's the easiet to use on eCS.
>
>If the RAM checks out OK, I probably should look at another set of 
>dump files, just to make sure the trap is consistent.
>

  I tried running MemTest86 from the link you gave and everything seems fine
after four times through - no errors. This hardware was new in March 2011:
Motherboard (Intel H55), CPU (i3), RAM (DDR3), Hard Drive (SATA II), CDROM
(SATA), Case and Power Supply (750W). Temperature of CPU, Power Supply or
motherboard has never hit 40 deg C.

  I will upload a new dump to the same location as before once I collect one.

Regards,

Dave McKenna



0
David
7/20/2011 10:04:55 PM
On Wed, 20 Jul 2011 22:04:55 UTC, "David McKenna" 
<davidmckenna@comcast.net> wrote:

Hi David,

>   I tried running MemTest86 from the link you gave and everything seems fine
> after four times through - no errors.

I figure the probability of a memory issue was low, but it's easy to 
check.

>This hardware was new in March 2011:

I tend to suspect new hardware more than something that's burned in 
for a while.

>   I will upload a new dump to the same location as before once I collect one.

Thanks.  The server is up.  If you get cascading dump files, just send
the 1st dump file and the .trp file.  The additional dump files have 
no useful info for what I am looking for.

BTW, is the system stable other than the Seamonkey expections?  I'm 
looking for possible patterns.

Steven

-- 
---------------------------------------------------------------------
Steven Levine <steve53@earthlink.bogus.net>
eCS/Warp/DIY etc. www.scoug.com www.ecomstation.com
---------------------------------------------------------------------
0
Steven
7/21/2011 3:18:38 AM
Steven,

On Wed, 20 Jul 2011 22:18:38 -0500, Steven Levine wrote:

>On Wed, 20 Jul 2011 22:04:55 UTC, "David McKenna" 
><davidmckenna@comcast.net> wrote:
>
>Hi David,
>
>>   I tried running MemTest86 from the link you gave and everything seems fine
>> after four times through - no errors.
>
>I figure the probability of a memory issue was low, but it's easy to 
>check.
>
>>This hardware was new in March 2011:
>
>I tend to suspect new hardware more than something that's burned in 
>for a while.
>
>>   I will upload a new dump to the same location as before once I collect one.
>
>Thanks.  The server is up.  If you get cascading dump files, just send
>the 1st dump file and the .trp file.  The additional dump files have 
>no useful info for what I am looking for.
>
>BTW, is the system stable other than the Seamonkey expections?  I'm 
>looking for possible patterns.
>

   Everything works fine - I have never had a crash in anything except
SeaMonkey (caused by either the TCPIP32 issue or Flash hangs). There is one
unusual characteristic. This motherboard supports up to 16GB RAM. I run with
2GB of RAM and have no trouble. If I put 4GB of RAM in (which I did when I
bought this stuff) then video performance is abysmally slow. I backed off to
2GB and video was normal again.

  I have a new dump file and *.trp I will upload. This one occurred when I
clicked on 'Help'->'About Plugins' just as the page finished displaying. I am
using the value '4' for all the 'Connections' settings found in
'about:config' per Bill Hartzell's suggestion. There was only one pdump.*
file this time and no POPUPLOG.

Regards,

Dave McKenna



0
David
7/21/2011 9:14:25 PM
On Thu, 21 Jul 2011 21:14:25 UTC, "David McKenna" 
<davidmckenna@comcast.net> wrote:

Hi David,

> 2GB of RAM and have no trouble. If I put 4GB of RAM in (which I did when I
> bought this stuff) then video performance is abysmally slow. I backed off to
> 2GB and video was normal again.

Is this with SNAP or Panorama?  Offhand, I would suspect a MTRRs 
problem.  Without proper write combining video is going to be slow, 
even with a shadow buffer.

>   I have a new dump file and *.trp I will upload. This one occurred when I
> clicked on 'Help'->'About Plugins' just as the page finished displaying.

Interesting.  Since the trap is related to reading the HOSTS file, I 
can only speculate as to how this might be related.

> I am
> using the value '4' for all the 'Connections' settings found in
> 'about:config' per Bill Hartzell's suggestion.

FWIW, I often wonder which universe Bill visits to come up with some 
of this stuff, but I doubt very much the connections value is going to
make a difference.

If you want to experiment, try configuring for one connection.  There 
is a slim possibility that this will prevent two instances of the 
nsHostResolver class from running.

>There was only one pdump.*
> file this time and no POPUPLOG.

The trap occurred for the same reason, but not quite in the same place
which might explain the different exception outputs.

I'm pretty well convinced we have a SMP race condition in the tcpip32 
code which handles tracking open file handles.  Specifically the trap 
occurs because the malloc/free routines used to manage the file handle
meta data is not MT-safe.  It appears that tcpip32 is statically 
linked to a non-MT-safe version of the the C runtime.  It also appears
that this was a known issue and tcpip32 contains MT-safe wrappers for 
the heap functions which are used in most cases.

We can only wonder why the maintainers did not relink to a MT-safe 
runtime.

With a bit of luck, I should be able to patch tcpip32.dll to use the 
the MT-safe wrappers.  The jumps and calls are all relative offsets.

I'll let you know when I have something to test.

Steven

-- 
---------------------------------------------------------------------
Steven Levine <steve53@earthlink.bogus.net>
eCS/Warp/DIY etc. www.scoug.com www.ecomstation.com
---------------------------------------------------------------------
0
Steven
7/22/2011 2:44:39 AM
On Tue, 19 Jul 2011 18:07:23 UTC, Bob Plyler <rplyler@us.nospam.ibm.com> wrote:

> >> Note: "future release" at this point means Firefox 8 at the earliest, 
> >> as 6 is already in beta, and 7 already in alpha.
> >
> > Has somebody decided that Firefox needs version-itis then?
> > How ridiculous.
> > Presumably they are trying to beat IE in the numbers game for whatever
> > small minded reasons...
> http://www.pcworld.com/article/231222/firefox_rapid_release_5_key_points.html


IMO just the final proof that the Firefox project managers have gone
completely off their rockers.

Fortunately I use SeaMonkey anyway.  Hopefully the SM developers are 
still at least somewhat sane.

-- 
Alex Taylor
Fukushima, Japan
http://www.socis.ca/~ataylo00

Please take off hat when replying.
0
Alex
7/22/2011 4:14:06 AM
Alex Taylor wrote:
> On Tue, 19 Jul 2011 18:07:23 UTC, Bob Plyler<rplyler@us.nospam.ibm.com>  wrote:
>
>>>> Note: "future release" at this point means Firefox 8 at the earliest,
>>>> as 6 is already in beta, and 7 already in alpha.
>>>
>>> Has somebody decided that Firefox needs version-itis then?
>>> How ridiculous.
>>> Presumably they are trying to beat IE in the numbers game for whatever
>>> small minded reasons...
>> http://www.pcworld.com/article/231222/firefox_rapid_release_5_key_points.html
>
>
> IMO just the final proof that the Firefox project managers have gone
> completely off their rockers.
>
> Fortunately I use SeaMonkey anyway.  Hopefully the SM developers are
> still at least somewhat sane.
>

Unluckily they are dependent on the Firefox developers.
Dave
0
Dave
7/22/2011 5:33:53 AM
On 07/21/11 07:44 pm, Steven Levine wrote:

> We can only wonder why the maintainers did not relink to a MT-safe
> runtime.

As strange as it sounds, IBM frequently chose to use non-IBM compilers, 
because it was cheaper to get proper support that way.
0
Steve
7/22/2011 5:50:35 AM
Sir:

David McKenna wrote:
<snip>
>
>     Everything works fine - I have never had a crash in anything except
> SeaMonkey (caused by either the TCPIP32 issue or Flash hangs). There is one
> unusual characteristic. This motherboard supports up to 16GB RAM. I run with
> 2GB of RAM and have no trouble. If I put 4GB of RAM in (which I did when I
> bought this stuff) then video performance is abysmally slow. I backed off to
> 2GB and video was normal again.
>

If your video driver setup will allow you to set the aperture size, set 
it to a value 64 MiB or less.  That reduces the area that the driver 
will attempt to update.  I know with the older SNAP-S3 driver that this 
could be set.  But I am using the SNAP generic VESA driver and its 
aperture size is fixed to 16 MiB.  I have a total frame buffer size of 3 
GiB (allocated by BIOS out of the total 8 GiB of memory in the machine), 
which if the driver attempted to update would be very slow using VESA & 
GRAD.  No video card, using the built-in video chip in the north bridge.

-- 
Bill
Thanks a Million!
0
William
7/22/2011 2:10:14 PM
Sir:

Steven Levine wrote:
<snip>
>> I am using the value '4' for all the 'Connections' settings found
>> in 'about:config' per Bill Hartzell's suggestion.
>
> FWIW, I often wonder which universe Bill visits to come up with some
>  of this stuff, but I doubt very much the connections value is going
> to make a difference.
>
> If you want to experiment, try configuring for one connection. There
> is a slim possibility that this will prevent two instances of the
> nsHostResolver class from running.
>
  I explained my reasoning that lost packets problem could be reduced by 
reducing the number of connections.  This would as a side effect reduce 
exposure to a possible race condition.  I refer you to RFC6274.txt, to 
section 4.1, Fragment reassembly.

Be that may, I tried the different protocol driver that was posted from 
OS/2 WORLD.  It has eliminated Those traps in TCPIP32.DLL for me, even 
with the original values restored to connections.

Are you saying that some traps occur because two or more threads are 
attempting to open the same HOST file?  That should be possible if they 
are not trying to get exclusive use.  Mark that file read only and see 
if that solves the problem.

In fixing David's residual problem you come up with a patch that
works-around the single thread problem in the linked in library within
TCPIP32.DLL, I would be pleased, And Hosannas would be due to you.

-- 
Bill
Thanks a Million!
0
William
7/22/2011 2:55:16 PM
Steven,

On Thu, 21 Jul 2011 21:44:39 -0500, Steven Levine wrote:

>On Thu, 21 Jul 2011 21:14:25 UTC, "David McKenna" 
><davidmckenna@comcast.net> wrote:
>
>Hi David,
>
>> 2GB of RAM and have no trouble. If I put 4GB of RAM in (which I did when I
>> bought this stuff) then video performance is abysmally slow. I backed off to
>> 2GB and video was normal again.
>
>Is this with SNAP or Panorama?  Offhand, I would suspect a MTRRs 
>problem.  Without proper write combining video is going to be slow, 
>even with a shadow buffer.

  This is with Panorama. With 4GB, SNAP would not load - the computer would
hang when the WPS was about to start (blank screen). I haven't tried SNAP
with 2GB yet. Now that Mensys has the source to SNAP, maybe this can be
fixed...

  I fiddled around with a utility called 'accmtrr.exe' I found on the
bugtracker and was able to get normal video performance (Panorama) with 4GB
RAM, but other things seemed messed up so eventually tried 2GB; it worked so
I stuck with that.

>
>>   I have a new dump file and *.trp I will upload. This one occurred when I
>> clicked on 'Help'->'About Plugins' just as the page finished displaying.
>
>Interesting.  Since the trap is related to reading the HOSTS file, I 
>can only speculate as to how this might be related.
>
>> I am
>> using the value '4' for all the 'Connections' settings found in
>> 'about:config' per Bill Hartzell's suggestion.
>
>FWIW, I often wonder which universe Bill visits to come up with some 
>of this stuff, but I doubt very much the connections value is going to
>make a difference.
>
>If you want to experiment, try configuring for one connection.  There 
>is a slim possibility that this will prevent two instances of the 
>nsHostResolver class from running.

  I tried using the value '1' for the connections, but I still got the
TCPIP32 crashes. Maybe not as much....

>
>>There was only one pdump.*
>> file this time and no POPUPLOG.
>
>The trap occurred for the same reason, but not quite in the same place
>which might explain the different exception outputs.
>
>I'm pretty well convinced we have a SMP race condition in the tcpip32 
>code which handles tracking open file handles.  Specifically the trap 
>occurs because the malloc/free routines used to manage the file handle
>meta data is not MT-safe.  It appears that tcpip32 is statically 
>linked to a non-MT-safe version of the the C runtime.  It also appears
>that this was a known issue and tcpip32 contains MT-safe wrappers for 
>the heap functions which are used in most cases.
>
>We can only wonder why the maintainers did not relink to a MT-safe 
>runtime.
>
>With a bit of luck, I should be able to patch tcpip32.dll to use the 
>the MT-safe wrappers.  The jumps and calls are all relative offsets.
>
>I'll let you know when I have something to test.
>

  I got your test version and will run it over the weekend. I set
'Connections' back to their original values. HT is turned 'on'. So far (about
45 minutes) no crashes... promising!

  This makes me wonder... what other MT unsafe things lurk in the dark heart
of OS/2?

Regards,

Dave McKenna





0
David
7/22/2011 10:31:42 PM
On 7/22/2011 3:31 PM, David McKenna wrote:

>>> 2GB of RAM and have no trouble. If I put 4GB of RAM in
> Now that Mensys has the source to SNAP, maybe this can be fixed...

You can't use 4GB or more of RAM with a 32-bit OS, unless the kernel 
supports PAE, or has ways of capping it to a lower value.  Windows XP 
usually reports somewhere between 3.0 - 3.7, and Windows NT6 (32-bit 
Vista and "7") they hacked to report 4, although it couldn't use it all.

You might do fine with 3GB, but the way OS/2 allocates memory pools is 
not conducive to modern systems, and you may still have issues.  In 
short, this is not really a video driver problem, even if changes made 
there could potentially help.

>    This makes me wonder... what other MT unsafe things lurk in the dark heart
> of OS/2?

Probably a fair number.  IBM was never very interested in making SMP 
work well.  I suspect that's because they didn't have enough big 
customers filing bugs for it.
0
Steve
7/22/2011 10:49:26 PM
On Fri, 22 Jul 2011 05:33:53 UTC, Dave Yeo <dave.r.yeo@gmail.com> wrote:

> > IMO just the final proof that the Firefox project managers have gone
> > completely off their rockers.
> >
> > Fortunately I use SeaMonkey anyway.  Hopefully the SM developers are
> > still at least somewhat sane.
> >
> 
> Unluckily they are dependent on the Firefox developers.

But they can determine their own release schedules and product support
policies, I hope...?

-- 
Alex Taylor
Fukushima, Japan
http://www.socis.ca/~ataylo00

Please take off hat when replying.
0
Alex
7/23/2011 4:50:03 AM
On Fri, 22 Jul 2011 22:49:26 UTC, Steve Wendt <spamsux@forgetit.org> 
wrote:

> You might do fine with 3GB, but the way OS/2 allocates memory pools is 
> not conducive to modern systems, and you may still have issues.  In 
> short, this is not really a video driver problem, even if changes made 
> there could potentially help.

My Lenovo ThinkPad T510 has 4 GB of memory in it. Win7, home premium, 
and eCS uses about 3 GB of it, with no problem. The rest is just 
ignored.

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

0
Doug
7/23/2011 5:22:11 AM
On 07/22/11 09:50 pm, Alex Taylor wrote:

>>> Fortunately I use SeaMonkey anyway.  Hopefully the SM developers are
>>> still at least somewhat sane.
>>
>> Unluckily they are dependent on the Firefox developers.
>
> But they can determine their own release schedules and product support
> policies, I hope...?

Sure, but with limited manpower, they are hard-pressed to deviate much. 
  SeaMonkey 2.2 = Firefox 5, SeaMonkey 2.3 = Firefox 6, etc.

You'll notice that everything but 2.2 is EOL:
http://releases.mozilla.org/pub/mozilla.org/seamonkey/releases/

There will be another Firefox 3.6.x, but there was no SeaMonkey that 
used that version of Gecko (SM2.0 = FF3.5 and SM2.1 = FF4).
0
Steve
7/23/2011 6:08:16 AM
Sir:

Doug Bissett wrote:
> On Fri, 22 Jul 2011 22:49:26 UTC, Steve Wendt<spamsux@forgetit.org>
> wrote:
>
>> You might do fine with 3GB, but the way OS/2 allocates memory pools is
>> not conducive to modern systems, and you may still have issues.  In
>> short, this is not really a video driver problem, even if changes made
>> there could potentially help.
>
> My Lenovo ThinkPad T510 has 4 GB of memory in it. Win7, home premium,
> and eCS uses about 3 GB of it, with no problem. The rest is just
> ignored.
>
I'd second Doug's comments.  What OS/2 does not see does not hurt the 
system.
-- 
Bill
Thanks a Million!
0
William
7/23/2011 12:54:25 PM
Rich Walsh wrote:
> On Tue, 12 Jul 2011 16:49:52 UTC, MCGJr<carl.gehr.DeSpam@DeSpam.mcgcg.com>  wrote:
>
>> I do a LOT of printing to PDFs that must be text-searchable
>
> Is there some problem with the PDFs that the Mozilla apps produce that
> make them unusable for you?  The text in the ones I just tried was
> fully searchable and selectable.

Rich, I was not saying that the PDFs were creating the stability 
problem.  My concern was the statement earlier in the thread that 
printing from SM to create a PDF would only be a graphic image of the 
characters and not searchable text.  I must have searchable text in the 
PDFs.



0
MCGJr
7/27/2011 7:06:07 AM
Reply: