SM 2.21b2 - incompatibility with updated xul.dll and Lightning 2.6.5

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

SM 2.21b2 - incompatibility with updated xul.dll and Lightning 2.6.5

Lewis Rosenthal-2
Hey, Dave...

*Finally* spent some quality time backing up my 15GB SM profile in
preparation for upgrading to SM 2.21 (backed up to 64GB unpartitioned FAT32
USB stick - thanks, Lars!!).

Went hunting for compatible Lightning, and found that you had uploaded 2.6.5
to Hobbes (thanks for that). (You should remove the older GData Provider
going forward, as the Google API has changed, and the older provider builds
will *not* function. It got so frustrating - even with current builds on
Linux - that I finally threw in the towel and switched to iCal; I blame all
of that on Google, but hey, it's their API, so they can do with it what they
wish.)

Anyway, after reading the thread here pertaining to beta 2, and seeing that
you had updated xul.dll, I grabbed that, too. Unfortunately, while SM seems
to start and run fine with it (have not flagged it for loading high), once I
installed Lightning 2.6.5, SM would not start. Lacking a map file or an xqs,
I don't have any good information, but my guess is that we need a rebuild of
Lightning, as replacing xul.dll with the one from the 2.21b2 zip worked
right out of the gate.

Red herring? I even had issues starting a profile with *no* calendars
configured, though I'm baffled as to why I couldn't even get safe mode to
come up (it's not like a bad plugin which is system-wide).

Anyway, I just wanted to report that to you.

Thanks - as always - for all of your hard work on these builds which are so
greatly appreciated.

Cheers

--
Lewis
-------------------------------------------------------------
Lewis G Rosenthal, CNA, CLP, CLE, CWTS
Rosenthal & Rosenthal, LLC                www.2rosenthals.com
Need a managed Wi-Fi hotspot?                www.hautspot.com
visit my IT blog                www.2rosenthals.net/wordpress
-------------------------------------------------------------
_______________________________________________
dev-ports-os2 mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-ports-os2
Reply | Threaded
Open this post in threaded view
|

Re: SM 2.21b2 - incompatibility with updated xul.dll and Lightning 2.6.5

Dave Yeo-3
Lewis Rosenthal wrote:
> Hey, Dave...
>
> *Finally* spent some quality time backing up my 15GB SM profile in
> preparation for upgrading to SM 2.21 (backed up to 64GB unpartitioned
> FAT32 USB stick - thanks, Lars!!).

I'd suggest deleting your cache and startup-cache directories before
backing up. I believe that every time Mozilla crashes it leaves orphaned
cache files. Probably a good idea for everyone to periodically clean
their cache.

>
> Went hunting for compatible Lightning, and found that you had uploaded
> 2.6.5 to Hobbes (thanks for that). (You should remove the older GData
> Provider going forward, as the Google API has changed, and the older
> provider builds will *not* function. It got so frustrating - even with
> current builds on Linux - that I finally threw in the towel and switched
> to iCal; I blame all of that on Google, but hey, it's their API, so they
> can do with it what they wish.)

OK, good to know. I just uploaded what I found in my tree after
building. Lightning may need updating after we switch to libc066 and the
newer GCC, something that I haven't got around to testing yet. Waiting
for the GCC builds to stabilize :)
>
> Anyway, after reading the thread here pertaining to beta 2, and seeing
> that you had updated xul.dll, I grabbed that, too. Unfortunately, while
> SM seems to start and run fine with it (have not flagged it for loading
> high), once I installed Lightning 2.6.5, SM would not start. Lacking a
> map file or an xqs, I don't have any good information, but my guess is
> that we need a rebuild of Lightning, as replacing xul.dll with the one
> from the 2.21b2 zip worked right out of the gate.

That was a test build for Lars, trying to resolve the crash when the
download manager opens, which of course doesn't happen here. It only had
a small change and I'm surprised Lightning didn't load for you.
I left it as it has the dbg stuff which will make a lot more informative
exceptq report, so instead of using a xqs file, use the dbg file.
It's a shame that they went to the monolithic xul as it is too hard to
upload test builds compared to a small DLL.

>
> Red herring? I even had issues starting a profile with *no* calendars
> configured, though I'm baffled as to why I couldn't even get safe mode
> to come up (it's not like a bad plugin which is system-wide).

Have you the latest exceptq installed? That was one thing that broke SM
for others, possibly the same with other dependencies though with up to
date RPM/YUM install it shouldn't be a problem.

>
> Anyway, I just wanted to report that to you.

Thanks for the report
Dave

>
> Thanks - as always - for all of your hard work on these builds which are
> so greatly appreciated.
>
> Cheers
>

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

Re: SM 2.21b2 - incompatibility with updated xul.dll and Lightning 2.6.5

Lewis Rosenthal-2
Hi, Dave...

Thanks for following up!

On 02/02/15 06:06 pm, Dave Yeo thus wrote :

> Lewis Rosenthal wrote:
>> Hey, Dave...
>>
>> *Finally* spent some quality time backing up my 15GB SM profile in
>> preparation for upgrading to SM 2.21 (backed up to 64GB unpartitioned
>> FAT32 USB stick - thanks, Lars!!).
>
> I'd suggest deleting your cache and startup-cache directories before backing
> up. I believe that every time Mozilla crashes it leaves orphaned cache
> files. Probably a good idea for everyone to periodically clean their cache.
>
Ah, indeed, good advice (which I forgot at the time - my startup script
actually has a switch to do this, as ISTR having to do it regularly some
builds back).

>>
>> Went hunting for compatible Lightning, and found that you had uploaded
>> 2.6.5 to Hobbes (thanks for that). (You should remove the older GData
>> Provider going forward, as the Google API has changed, and the older
>> provider builds will *not* function. It got so frustrating - even with
>> current builds on Linux - that I finally threw in the towel and switched
>> to iCal; I blame all of that on Google, but hey, it's their API, so they
>> can do with it what they wish.)
>
> OK, good to know. I just uploaded what I found in my tree after building.
> Lightning may need updating after we switch to libc066 and the newer GCC,
> something that I haven't got around to testing yet. Waiting for the GCC
> builds to stabilize :)

Sounds good.

Yeah, Philipp had a real time of it during the transition to the new API. I
followed for a time, but the noise became overwhelming (and I was just
listening, not responding or fixing). Once Google shut down the older API,
the calendars stopped syncing entirely, as the new API is not backward
compatible (read: completely intolerant) of older clients. While less
feature rich, at least iCal is an independent standard, so I switched. I had
a similar adventure on my aging HP Touchpad tablet, so now, I'm "iCal" all
the way around.

>>
>> Anyway, after reading the thread here pertaining to beta 2, and seeing
>> that you had updated xul.dll, I grabbed that, too. Unfortunately, while
>> SM seems to start and run fine with it (have not flagged it for loading
>> high), once I installed Lightning 2.6.5, SM would not start. Lacking a
>> map file or an xqs, I don't have any good information, but my guess is
>> that we need a rebuild of Lightning, as replacing xul.dll with the one
>> from the 2.21b2 zip worked right out of the gate.
>
> That was a test build for Lars, trying to resolve the crash when the
> download manager opens, which of course doesn't happen here. It only had a
> small change and I'm surprised Lightning didn't load for you.
> I left it as it has the dbg stuff which will make a lot more informative
> exceptq report, so instead of using a xqs file, use the dbg file.
> It's a shame that they went to the monolithic xul as it is too hard to
> upload test builds compared to a small DLL.
>
Agreed. It's unwieldy due to its size. Have you had better luck with this
one loading high (I also have not seen issues with the download manager and
the "default" dll; I noticed some mention of yours pertaining to loading
high, though)? Currently, with about a half dozen tabs open, as well as
email, I can't start AOO 4.1.1 (nothing flagged for loading high in either app).

>>
>> Red herring? I even had issues starting a profile with *no* calendars
>> configured, though I'm baffled as to why I couldn't even get safe mode
>> to come up (it's not like a bad plugin which is system-wide).
>
> Have you the latest exceptq installed? That was one thing that broke SM for
> others, possibly the same with other dependencies though with up to date
> RPM/YUM install it shouldn't be a problem.
>
>>
>> Anyway, I just wanted to report that to you.
>
> Thanks for the report

You bet!

--
Lewis
-------------------------------------------------------------
Lewis G Rosenthal, CNA, CLP, CLE, CWTS
Rosenthal & Rosenthal, LLC                www.2rosenthals.com
Need a managed Wi-Fi hotspot?                www.hautspot.com
visit my IT blog                www.2rosenthals.net/wordpress
-------------------------------------------------------------
_______________________________________________
dev-ports-os2 mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-ports-os2
Reply | Threaded
Open this post in threaded view
|

Re: SM 2.21b2 - incompatibility with updated xul.dll and Lightning 2.6.5

Dave Yeo-3
On 02/02/15 10:13 PM, Lewis Rosenthal wrote:
> Agreed. It's unwieldy due to its size. Have you had better luck with
> this one loading high (I also have not seen issues with the download
> manager and the "default" dll; I noticed some mention of yours
> pertaining to loading high, though)? Currently, with about a half dozen
> tabs open, as well as email, I can't start AOO 4.1.1 (nothing flagged
> for loading high in either app).

Loading high works for the  SeaMonkey DLLs as long as you only load the
code high in xul.dll.
Dave
_______________________________________________
dev-ports-os2 mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-ports-os2
Reply | Threaded
Open this post in threaded view
|

Re: SM 2.21b2 - incompatibility with updated xul.dll and Lightning 2.6.5

Gabriele Gamba
In reply to this post by Lewis Rosenthal-2
On Mon, 2 Feb 2015 21:15:21 UTC, Lewis Rosenthal
<[hidden email]> wrote:

>
> *Finally* spent some quality time backing up my 15GB SM profile in
> preparation for upgrading to SM 2.21 (backed up to 64GB unpartitioned FAT32
> USB stick - thanks, Lars!!).
>

Could you write to a unpartitioned USB stick with OS/2? Did I miss
something??

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

[OT] Large floppy FAT32 USB (was: Re: SM 2.21b2 - incompatibility with updated xul.dll and Lightning 2.6.5)

Lewis Rosenthal-2
Hi, Gabriele...

On 02/03/15 09:48 am, Gabriele Gamba thus wrote :

> On Mon, 2 Feb 2015 21:15:21 UTC, Lewis Rosenthal
> <[hidden email]> wrote:
>
>>
>> *Finally* spent some quality time backing up my 15GB SM profile in
>> preparation for upgrading to SM 2.21 (backed up to 64GB unpartitioned FAT32
>> USB stick - thanks, Lars!!).
>>
>
> Could you write to a unpartitioned USB stick with OS/2? Did I miss
> something??
>
Under development, and not quite ready for prime time (I'm currently seeing
issues now with large *partitioned* media not being mounted), but yes, Lars
has worked out a method for accessing >2GB FAT16/32-formatted USB sticks.
one of my test sticks is a 64MB SanDisk Cruzer, formatted FAT32 with *no*
partitioning (and thus, no LVM).

We're still a little way from seeing this as GA code (and likely, you will
see it first in Lars' branch, which is essentially the experimental branch
of the overall USB project).

Great work, though, and I'm glad to have contributed some testing along the way.

Cheers

--
Lewis
-------------------------------------------------------------
Lewis G Rosenthal, CNA, CLP, CLE, CWTS
Rosenthal & Rosenthal, LLC                www.2rosenthals.com
Need a managed Wi-Fi hotspot?                www.hautspot.com
visit my IT blog                www.2rosenthals.net/wordpress
-------------------------------------------------------------
_______________________________________________
dev-ports-os2 mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-ports-os2
Reply | Threaded
Open this post in threaded view
|

Re: SM 2.21b2 - incompatibility with updated xul.dll and Lightning 2.6.5

Lewis Rosenthal-2
In reply to this post by Lewis Rosenthal-2
Hi, Dave...

On 02/03/15 02:05 am, Dave Yeo thus wrote :

> On 02/02/15 10:13 PM, Lewis Rosenthal wrote:
>> Agreed. It's unwieldy due to its size. Have you had better luck with
>> this one loading high (I also have not seen issues with the download
>> manager and the "default" dll; I noticed some mention of yours
>> pertaining to loading high, though)? Currently, with about a half dozen
>> tabs open, as well as email, I can't start AOO 4.1.1 (nothing flagged
>> for loading high in either app).
>
> Loading high works for the  SeaMonkey DLLs as long as you only load the code
> high in xul.dll.

Thanks for this.

FWIW (and as I missed responding to your question in my last reply), I *am*
using the latest exceptq. Using the original xul.dll, I got a trap this
morning following a download and then an attempt to open it
(unrecognized/unassociated mime type; it was a patch file, i.e.,
blah-blah.patch).

Beginning of TRP file is:

______________________________________________________________________

  Exception Report - created 2015/02/03 11:21:22
______________________________________________________________________

  OS2/eCS Version:  2.45
  # of Processors:  1
  Physical Memory:  1982 mb
  Virt Addr Limit:  2048 mb
  Exceptq Version:  7.11-shl (Mar  3 2014)

______________________________________________________________________

  Exception C0000005 - Access Violation
______________________________________________________________________

  Process:  J:\MOZILLA.ORG\SEAMONKEY\SEAMONKEY.EXE
  PID:      BD (189)
  TID:      01 (1)
  Priority: 200

  Filename: J:\MOZILLA.ORG\SEAMONKEY\XUL.DLL 12/31/2014 06:46:10 32,894,720
  Address:  005B:1390283C (0001:0040283C)
  Cause:    Attempted to read from 000004D4
            (not a valid address)

______________________________________________________________________

  Failing Instruction
______________________________________________________________________

  1390282D  MOV  ESI, [ESP+0x48]       (8b7424 48)
  13902831  MOV  EAX, [ESI+0x8]        (8b46 08)
  13902834  TEST EAX, EAX              (85c0)
  13902836  JZ   0x13902de0            (0f84 a4050000)
  1390283C >MOV  ECX, [EAX+0x330]      (8b88 30030000)
  13902842  CMP  [ESI+0x30], ECX       (394e 30)
  13902845  JZ   0x13902de0            (0f84 95050000)
  1390284B  CMP  BYTE [ESI+0x34], 0x0  (807e 34 00)

______________________________________________________________________

  Registers
______________________________________________________________________

  EAX : 000001A4   EBX  : 0012F15C   ECX : 1BC00002   EDX  : 2003013C
  ESI : 336A38A0   EDI  : 30B42520
  ESP : 0012E274   EBP  : 0000003C   EIP : 1390283C   EFLG : 00010202
  CS  : 005B       CSLIM: FFFFFFFF   SS  : 0053       SSLIM: FFFFFFFF

  EAX : not a valid address
  EBX : read/write memory on this thread's stack
  ECX : read/write memory - owner unknown
  EDX : read/write memory allocated by LIBC066
  ESI : read/write memory allocated by LIBC066
  EDI : read/write memory allocated by LIBC066

______________________________________________________________________

  Stack Info for Thread 01
______________________________________________________________________

    Size       Base        ESP         Max         Top
  00100000   00130000 -> 0012E274 -> 00116000 -> 00030000

______________________________________________________________________

  Call Stack
______________________________________________________________________

    EBP     Address    Module     Obj:Offset    Nearest Public Symbol
  --------  ---------  --------  -------------  -----------------------
  Trap  ->  1390283C   XUL       0001:0040283C  between
mozilla::FrameLayerBuilder::DrawThebesLayer + 73C and
nsTArray_base::SwapArrayElements - 1124  (both in FrameLayerBuilder.o)

  Lost Stack chain - invalid EBP 0000003C

Not sure if this correlates with what Lars was seeing. Again, I haven't yet
marked anything for loading high, and this is the first time I've seen a
trap (I have opened other *recognized* mime types (pdfs, mainly, which are
set to open in Lucide).

The only other change is that I rebuilt the Evernote web clipper to bring it
to version 5.9.1 (my previous build was a 5.8 one). (I don't "officially"
release those due to licensing concerns - Evernote has not GPL'd the code,
and they have yet to respond to my request to make their web clipper
extension compatible with SeaMonkey, despite my providing them with a diff.
Still, I have a couple of clients who have requested it for SeaMonkey, and
have modified the code for them. Adventurous souls might even find a test
version on my FTP server...who knows?)

Anyway, I don't suspect that extension to have triggered the trap in this
instance. If the full trp file is of interest, I can send it via PM.

Cheers

--
Lewis
-------------------------------------------------------------
Lewis G Rosenthal, CNA, CLP, CLE, CWTS
Rosenthal & Rosenthal, LLC                www.2rosenthals.com
Need a managed Wi-Fi hotspot?                www.hautspot.com
visit my IT blog                www.2rosenthals.net/wordpress
-------------------------------------------------------------
_______________________________________________
dev-ports-os2 mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-ports-os2
Reply | Threaded
Open this post in threaded view
|

Re: SM 2.21b2 - incompatibility with updated xul.dll and Lightning 2.6.5

Ray Davison
In reply to this post by Lewis Rosenthal-2
Lewis Rosenthal wrote:
> Hey, Dave...
>
> *Finally* spent some quality time backing up my 15GB SM profile

15GB profile?  I can only assume you have your mail files in the profile
tree.  If so, I suggest you give them their own tree.  One reason is
that it allows you to have a selection of profiles that all use the same
mail files.

> in preparation for upgrading to SM 2.21

"Upgrading" SM?  That typically means replacing whatever version you had
before.  I never replace an OS or an app until I have determined that
the newer is better.  And SM makes it so easy to have an many versions
as you have HDD space - all using the same profile or each being able to
chose from as many profiles as you care to create.

And, don't you have more than one computer.  "Backup" of SM, is copy the
whole thing to another machine.  Mine gets "backed up" every time I go
on the road, because the files move from desktop to laptop and back.

Ray

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

Re: SM 2.21b2 - incompatibility with updated xul.dll and Lightning 2.6.5

Ray Davison
In reply to this post by Gabriele Gamba
Gabriele Gamba wrote:
>
> Could you write to a unpartitioned USB stick with OS/2? Did I miss
> something??
>
USB sticks on eCS is iffy.  I have a 2002 AMD that with eCS2.0, ran USB
sticks out-of-the-box up to 32G.  That was in a floppy/memory card combo
drive.  Now, with eCS2.1, it is OK with SD cards but not sticks.

Ray


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

Re: SM 2.21b2 - incompatibility with updated xul.dll and Lightning 2.6.5

Dave Yeo-3
In reply to this post by Lewis Rosenthal-2
Lewis Rosenthal wrote:
> FWIW (and as I missed responding to your question in my last reply), I
> *am* using the latest exceptq. Using the original xul.dll, I got a trap
> this morning following a download and then an attempt to open it
> (unrecognized/unassociated mime type; it was a patch file, i.e.,
> blah-blah.patch).
>
> Beginning of TRP file is:
[...]

> ______________________________________________________________________
>
>   Call Stack
> ______________________________________________________________________
>
>     EBP     Address    Module     Obj:Offset    Nearest Public Symbol
>   --------  ---------  --------  -------------  -----------------------
>   Trap  ->  1390283C   XUL       0001:0040283C  between
> mozilla::FrameLayerBuilder::DrawThebesLayer + 73C and
> nsTArray_base::SwapArrayElements - 1124  (both in FrameLayerBuilder.o)

This looks familiar. I suspect that occasionally Cairo goes out of
bounds but I don't have the skills to debug it, especially without it
affecting me.

>
>   Lost Stack chain - invalid EBP 0000003C

I think this is what they're trying to currently fix in GCC so the stack
chain is more complete.

>
> Not sure if this correlates with what Lars was seeing. Again, I haven't
> yet marked anything for loading high, and this is the first time I've
> seen a trap (I have opened other *recognized* mime types (pdfs, mainly,
> which are set to open in Lucide).

I'm not sure if related but may be. For most people suffering the
download manager crash, clearing the list helps. Lars has it bad though.
Workaround is not to use the download manager for now.
(preferences-->browser-->downloads-->Open a progress dialog).
I have had quite a few problems with RWS over the years, crashes,
freezes and even with Thunderbird where only the frame was responsive
though usually no trp report. Fix is to set MOZ_NO_RWS=1.
Dave
_______________________________________________
dev-ports-os2 mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-ports-os2
Reply | Threaded
Open this post in threaded view
|

Re: SM 2.21b2 - incompatibility with updated xul.dll and Lightning 2.6.5

Steven Levine-3
On Wed, 4 Feb 2015 00:26:49 UTC, Dave Yeo <[hidden email]>
wrote:

Hi Dave,

> This looks familiar. I suspect that occasionally Cairo goes out of
> bounds but I don't have the skills to debug it, especially without it
> affecting me.

A couple of comments that might help you know where to look.

This

  1390283C >MOV  ECX, [EAX+0x330]      (8b88 30030000)

and

EAX : 000001A4

and the fact that the code is C++ implies that there is a missing null
pointer check.  When a class contains embedded subclasses, accessors
for the subclass objects often look like

  lea eax [eax+0x1a4]

where eax points to the parent class object.  If the null check for
the parent class object is missing, the result will be a trap like
Lewis encountered.


> I think this is what they're trying to currently fix in GCC so the stack
> chain is more complete.

Yes, they are.  The compiler was defaulting to generating better
optimized code rather than generating standard stack frames (i.e. ebp
always points to the parent frame).  It's a typical time space
tradeoff.

It's not that the stack chain is imcomplete.  It's just that exceptq
is not smart enough to find it.  It can be found and debuggers such as
the OpenWatcom can do this.  Exceptq may eventually get some ability
to do this too.

You can probably debug the exception given a full .trp file.  The
Labels on Stack section will give you hints of which function might be
the caller and this can be verfied by examining the stack dump.

If you have build of xul.dll with debug symbols, you can use it to
convert the function offsets to line numbers.

Steven


--
---------------------------------------------------------------------
Steven Levine <[hidden email]>
DIY/Warp/eCS etc. www.scoug.com
---------------------------------------------------------------------
_______________________________________________
dev-ports-os2 mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-ports-os2
Reply | Threaded
Open this post in threaded view
|

SM upgrade considerations (was: Re: SM 2.21b2 - incompatibility with updated xul.dll and Lightning 2.6.5)

Lewis Rosenthal-2
In reply to this post by Ray Davison
Hi, Ray...

On 02/03/15 01:06 pm, Ray Davison thus wrote :
> Lewis Rosenthal wrote:
>> Hey, Dave...
>>
>> *Finally* spent some quality time backing up my 15GB SM profile
>
> 15GB profile?  I can only assume you have your mail files in the profile
> tree.  If so, I suggest you give them their own tree.  One reason is that it
> allows you to have a selection of profiles that all use the same mail files.
>
I utilize a mix of IMAP and POP3, which allows me to maintain different
filtering for the same mailbox on my server, as well as "live" backup. No
POP3 mail folder is allowed to grow beyond 20,000 messages, and the POP3
Inbox is routinely culled to under 2,000 messages (about one month's worth,
*after* filtering).

I have several other profiles. This was my main one. I use the others for
testing and extension development. I didn't back those up before the
upgrade, as they weren't really important.

I don't like sharing mail folders between profiles, mainly because of how I
use profiles. That's just my usage of the program, of course. I can see the
value in doing that (for some).

>> in preparation for upgrading to SM 2.21
>
> "Upgrading" SM?  That typically means replacing whatever version you had
> before.  I never replace an OS or an app until I have determined that the
> newer is better.  And SM makes it so easy to have an many versions as you
> have HDD space - all using the same profile or each being able to chose from
> as many profiles as you care to create.
>
I rename the previous program directory and create a new "seamonkey"
directory. My script simply points to J:\mozilla.org\seamonkey\seamonkey.exe
(with appropriate environment settings and such) to start it. Thus, I can
*usually* switch back and forth between minor versions by just renaming
directories.

As I do quite a bit of extension maintenance (FF or TB extensions modified
for SM or non-OS/2-aware extensions modified for OS/2), it's easier to
support one 2.x version at a time vs swapping around. ;-)


> And, don't you have more than one computer.  "Backup" of SM, is copy the
> whole thing to another machine.  Mine gets "backed up" every time I go on
> the road, because the files move from desktop to laptop and back.
>
"backup" for me means backup to tape every night across the LAN. I do have
multiple systems, but my POP3 install *only* lives on my daily driver (this
T43, currently running eCS 2.1). I could have relied on the tape backup, but
what a pain in case a full restore is needed, when I can just copy the whole
thing to a stick. :-)

In your case, you could even keep your profile ona  stick and just move the
stick from laptop to desktop. Using LVM, the drive letter of the stick would
be, well, stuck (LOL). From there, a backup to the local drive could also be
achieved. However, whatever works for each of us should be the order of the day.

Cheers

--
Lewis
-------------------------------------------------------------
Lewis G Rosenthal, CNA, CLP, CLE, CWTS
Rosenthal & Rosenthal, LLC                www.2rosenthals.com
Need a managed Wi-Fi hotspot?                www.hautspot.com
visit my IT blog                www.2rosenthals.net/wordpress
-------------------------------------------------------------
_______________________________________________
dev-ports-os2 mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-ports-os2
Reply | Threaded
Open this post in threaded view
|

Re: SM 2.21b2 - incompatibility with updated xul.dll and Lightning 2.6.5

Lewis Rosenthal-2
In reply to this post by Steven Levine-3
Hi...

On 02/05/15 02:54 pm, Steven Levine thus wrote :

> On Wed, 4 Feb 2015 00:26:49 UTC, Dave Yeo <[hidden email]>
> wrote:
>
> Hi Dave,
>
>> This looks familiar. I suspect that occasionally Cairo goes out of
>> bounds but I don't have the skills to debug it, especially without it
>> affecting me.
>
> A couple of comments that might help you know where to look.
>
> This
>
>    1390283C >MOV  ECX, [EAX+0x330]      (8b88 30030000)
>
> and
>
> EAX : 000001A4
>
> and the fact that the code is C++ implies that there is a missing null
> pointer check.  When a class contains embedded subclasses, accessors
> for the subclass objects often look like
>
>    lea eax [eax+0x1a4]
>
> where eax points to the parent class object.  If the null check for
> the parent class object is missing, the result will be a trap like
> Lewis encountered.
>
>
>> I think this is what they're trying to currently fix in GCC so the stack
>> chain is more complete.
>
> Yes, they are.  The compiler was defaulting to generating better
> optimized code rather than generating standard stack frames (i.e. ebp
> always points to the parent frame).  It's a typical time space
> tradeoff.
>
> It's not that the stack chain is imcomplete.  It's just that exceptq
> is not smart enough to find it.  It can be found and debuggers such as
> the OpenWatcom can do this.  Exceptq may eventually get some ability
> to do this too.
>
> You can probably debug the exception given a full .trp file.  The
> Labels on Stack section will give you hints of which function might be
> the caller and this can be verfied by examining the stack dump.
>
> If you have build of xul.dll with debug symbols, you can use it to
> convert the function offsets to line numbers.
>

We may want to spend some quality time with this, assuming Lars and I are
not the only ones seeing it (I can - and do - get a consistent crash
immediately following the download (or saving/detaching an email attachment)
just as the download manager window is opening, or if it is already open,
then when focus shifts to it. I did not see this with the other xul.dll
which Dave built for Lars (but of course, I can't get Lightning to load with
that one). I've tried emptying the download manager, but this makes no
difference.

Marking all possible dlls to load code high (I haven't tried code+data)
makes no difference.

I haven't used the newer FF long enough to see if I get the same type of
crashes with it. This one drove me nuts today in SM, though, to the point
where I was about to disable Lightning just to put the other xul.dll back in
place.

Let me know what I can do to help with this, if indeed there is anything at
this point (of course, if this is likely to be fixed in the underlying FF
code, then we should just wait and not waste time and resources on this, here).

Cheers

--
Lewis
-------------------------------------------------------------
Lewis G Rosenthal, CNA, CLP, CLE, CWTS
Rosenthal & Rosenthal, LLC                www.2rosenthals.com
Need a managed Wi-Fi hotspot?                www.hautspot.com
visit my IT blog                www.2rosenthals.net/wordpress
-------------------------------------------------------------
_______________________________________________
dev-ports-os2 mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-ports-os2
Reply | Threaded
Open this post in threaded view
|

Re: SM upgrade considerations

Dave Yeo-3
In reply to this post by Lewis Rosenthal-2
On 02/05/15 09:30 PM, Lewis Rosenthal wrote:
> "backup" for me means backup to tape every night across the LAN. I do
> have multiple systems, but my POP3 install *only* lives on my daily
> driver (this T43, currently running eCS 2.1). I could have relied on the
> tape backup, but what a pain in case a full restore is needed, when I
> can just copy the whole thing to a stick. :-)

How long did it take to backup to the stick? Here it seems to take
forever just to backup a couple of gigs.

>
> In your case, you could even keep your profile ona  stick and just move
> the stick from laptop to desktop. Using LVM, the drive letter of the
> stick would be, well, stuck (LOL). From there, a backup to the local
> drive could also be achieved. However, whatever works for each of us
> should be the order of the day.

Seems the performance of having the profile on a stick would be
terrible. I find, with TB, that I need to defrag the mailboxes regularly
or performance suffers.
Dave
_______________________________________________
dev-ports-os2 mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-ports-os2
Reply | Threaded
Open this post in threaded view
|

Re: SM 2.21b2 - incompatibility with updated xul.dll and Lightning 2.6.5

Dave Yeo-3
In reply to this post by Lewis Rosenthal-2
On 02/05/15 09:41 PM, Lewis Rosenthal wrote:
[...]
>
> We may want to spend some quality time with this, assuming Lars and I
> are not the only ones seeing it (I can - and do - get a consistent crash
> immediately following the download (or saving/detaching an email
> attachment) just as the download manager window is opening, or if it is
> already open, then when focus shifts to it. I did not see this with the
> other xul.dll which Dave built for Lars (but of course, I can't get
> Lightning to load with that one). I've tried emptying the download
> manager, but this makes no difference.

Others have seen it (clearing the list helped) and I believe I saw it
when I first built SM but I cleared the list and the problem went away
and didn't come back even though I now have a large list in the download
manager. Lars reported having the same problem with the test xul.dll.
For now you can just not use the download manager,
Preferences-->browser-->Downloads and click Open a progress dialog.

>
> Marking all possible dlls to load code high (I haven't tried code+data)
> makes no difference.
>
> I haven't used the newer FF long enough to see if I get the same type of
> crashes with it. This one drove me nuts today in SM, though, to the
> point where I was about to disable Lightning just to put the other
> xul.dll back in place.

Firefox doesn't seem to trigger the crash. Of course it has its own
download manager.

>
> Let me know what I can do to help with this, if indeed there is anything
> at this point (of course, if this is likely to be fixed in the
> underlying FF code, then we should just wait and not waste time and
> resources on this, here).

I'm sure that if we can find a missing null pointer check, dmik would
fix it as it is an obvious bug, and if he didn't, well I've already
forked his code to re-add sydneyaudio.
The problem is bandwidth, with the size of xul.dll it is non-trivial for
me to keep uploading test builds. Lars had a couple of ideas but they
make no difference here and it is too hard to upload.
Once I finish updating RPM to the newer GCC (turning into gcc dll hell)
I'll rebuild SM twice. Once with xqs files and once with debug symbols
and we can revisit this.
Another problem is that the debug build of SM I built (hard as i don't
have enough ram, only 2GB) throws too many exceptions and doesn't run
long enough to even test the download manager using my usual profile and
my skills are lacking.
Dave


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

Re: SM 2.21b2 - incompatibility with updated xul.dll and Lightning 2.6.5

Dave Yeo-3
In reply to this post by Lewis Rosenthal-2
Dave Yeo wrote:
> Once I finish updating RPM to the newer GCC (turning into gcc dll hell)
> I'll rebuild SM twice. Once with xqs files and once with debug symbols
> and we can revisit this.

Ran into a missing symbol in libos2 (SafeWinUpper) which is in the
official release, bug filed
Dave
_______________________________________________
dev-ports-os2 mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-ports-os2
Reply | Threaded
Open this post in threaded view
|

Re: SM upgrade considerations

Ray Davison
In reply to this post by Lewis Rosenthal-2
Lewis Rosenthal wrote:

> "backup" for me means backup to tape every night across the LAN.

What is the size of tapes now?  I had a tape drive once.  it is now in a
box in the shop.  It failed to restore.  That is when I went to front
panel plug in HDDs.  And I can get just one file if I want it.  And I
don't think you can beat the copy speed.
>
> In your case, you could even keep your profile ona  stick and just move
> the stick from laptop to desktop. Using LVM, the drive letter of the
> stick would be, well, stuck (LOL).

But since I don't use LVM, I don't have any "stuck" drive letters on
sticks.  I am at this moment looking at a 30G stick.  I did nothing to
prep it.  DFSee says it has 2.9M free space and a 30G primary FAT32.

I also use SD cards.  My desk tops all have combo floppy/card/USB
drives.  Yes I still use floppies.  The functionally has never been
replaced.

And in case someone missed the memo, malware can ride in the firmware of
sticks.

Ray


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

Re: SM 2.21b2 - incompatibility with updated xul.dll and Lightning 2.6.5

Andy-330
In reply to this post by Steven Levine-3
On Fri, 6 Feb 2015 06:24:54 UTC, Dave Yeo <[hidden email]>
wrote:

> On 02/05/15 09:41 PM, Lewis Rosenthal wrote:
> [...]
> >
> > We may want to spend some quality time with this, assuming Lars and I
> > are not the only ones seeing it (I can - and do - get a consistent crash
> > immediately following the download (or saving/detaching an email
> > attachment) just as the download manager window is opening, or if it is
> > already open, then when focus shifts to it. I did not see this with the
> > other xul.dll which Dave built for Lars (but of course, I can't get
> > Lightning to load with that one). I've tried emptying the download
> > manager, but this makes no difference.
>
> Others have seen it (clearing the list helped) and I believe I saw it
> when I first built SM but I cleared the list and the problem went away
> and didn't come back even though I now have a large list in the download
> manager. Lars reported having the same problem with the test xul.dll.
> For now you can just not use the download manager,
> Preferences-->browser-->Downloads and click Open a progress dialog.
>
> >
> > Marking all possible dlls to load code high (I haven't tried code+data)
> > makes no difference.
> >
> > I haven't used the newer FF long enough to see if I get the same type of
> > crashes with it. This one drove me nuts today in SM, though, to the
> > point where I was about to disable Lightning just to put the other
> > xul.dll back in place.
>
> Firefox doesn't seem to trigger the crash. Of course it has its own
> download manager.
>
> >
> > Let me know what I can do to help with this, if indeed there is anything
> > at this point (of course, if this is likely to be fixed in the
> > underlying FF code, then we should just wait and not waste time and
> > resources on this, here).
>
> I'm sure that if we can find a missing null pointer check, dmik would
> fix it as it is an obvious bug, and if he didn't, well I've already
> forked his code to re-add sydneyaudio.
> The problem is bandwidth, with the size of xul.dll it is non-trivial for
> me to keep uploading test builds. Lars had a couple of ideas but they
> make no difference here and it is too hard to upload.
> Once I finish updating RPM to the newer GCC (turning into gcc dll hell)
> I'll rebuild SM twice. Once with xqs files and once with debug symbols
> and we can revisit this.
> Another problem is that the debug build of SM I built (hard as i don't
> have enough ram, only 2GB) throws too many exceptions and doesn't run
> long enough to even test the download manager using my usual profile and
> my skills are lacking.
> Dave
>
>

Clearing the list helps here, or if I forget then I have to delete
downloads.sqlite.
--

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