Author Topic: SeaMonkey/2.42.9esr Build-Identifikator: 20200307211800 - crashes without .trp  (Read 643 times)

Andi B.

  • Hero Member
  • *****
  • Thank You
  • -Given: 1
  • -Receive: 24
  • Posts: 501
    • View Profile
A few days ago I though I give the newest SM version a try. But it behaves not very stable on my system. Every now and then it crashes without any .trp file or popuplog.os2 entry.

Before I heavy used SeaMonkey/2.42.9esr Build-Identifikator: 20190520220003 which is much more stable. But as I now do much wiki (confluence) editing it sooner or later eats up all higher shared memory. At that time it becomes very unresponsive. So I though I try the newest version.

First thing I noticed with the new version is, it uses more of the rpm dlls and does not provide the same in it's own directory. That's good IMO. But I had to update nss... packages from netlabs exp repository. Otherwise sites which needs TLS1.2 did not work. Okay I've no big problem using the exp repository. But I can't get this version as near as stable than the older one.

I tried a new profile without much success. Although startup is now way faster cause with my standard profile I usually automatically load email and calendar too. But the new profile without any extensions did not help either.

What makes me wonder is that SM does not create .trp files anymore. The older version did.  Anyone else seeing such problems? Dave here ;-)

Dave Yeo

  • Hero Member
  • *****
  • Thank You
  • -Given: 11
  • -Receive: 181
  • Posts: 2490
    • View Profile
Yes, it is a known issue with the SM linked against the RPM NSPR/NSS where the browser silently vanishes without a trp file created. It will create a trp file for other crashes.
https://github.com/bitwiseworks/nss-os2/issues/1
I'd advice using the build with included NSPR/NSS for now. I've been struggling to build it with the new GCC, which hopefully will fix this issue.
As for high memory, our kernel has a bug where high memory isn't freed when closing an app. You can see with Theseus that zombie shared high memory holes are left and after a few opens and closes, high memory runs out. Work around is to install smturbo to keep the DLLs loaded.

Andi B.

  • Hero Member
  • *****
  • Thank You
  • -Given: 1
  • -Receive: 24
  • Posts: 501
    • View Profile
Now I've updated to
Code: [Select]
Build-Identifikator: 20200424181102At that time I also updated all dependencies listed in RPM_REQUIREMENTS. So far so good. But now my AOO 4.1.7 does not work any more. It shows the splash screen but then ends.

In popuplog.os2 there I find -
Code: [Select]
04-30-2020  16:31:55  SYS2070  PID 04b3  TID 0001  Slot 00ea
P:\OPENOFFICE4.1.7\PROGRAM\SOFFICE.BIN
I18NPOOL->ICUUC.__ZN3icu22RuleBasedBreakIterator5resetEv
127

I know this is not strictly related to SM. But I wonder how others managed to run latest SM and AOO in parallel.

Dave Yeo

  • Hero Member
  • *****
  • Thank You
  • -Given: 11
  • -Receive: 181
  • Posts: 2490
    • View Profile
Sounds like the recent ICU update broke AOO, if no one has a better idea, you might need to open an issue at Bitwises Github page on ICU.