OS/2, eCS & ArcaOS - Technical > Applications

LIBC panic errors anyone?

<< < (2/5) > >>

Dariusz Piatkowski:
Lars,


--- Quote from: Lars on January 10, 2022, 10:12:22 am ---...Don't shoot the messenger. It looks like there is an actual improvement in libc to properly report if you call "free" on the very same pointer more than once (which is forbidden)...
--- End quote ---

Thanks for that input...I started to review each trap report closer to see what might be the root cause. I have consistently seen what appear to be memory calls.

The good news is that CRON/2, which is the one most often showing these, had been released with source. That means I can attempt to debug (and probably learn a pile more while doing so).

Thank you, insight greatly appreciated!

Dave Yeo:
Yes, often the Mozilla trps seem to originate in the JavaScript engines garbage collection routines, I thought during allocation. Doing garbage collection in C++ is likely complicated. The last one here seems to have originated from doing a malloc,

--- Code: --- 0013F818  BB4F5160   XUL       0001:03315160  between _moz_xmalloc + 10 and _moz_xcalloc - 20  (both in Unified_cpp_memory_mozalloc0.cpp)

--- End code ---
When getting Mozilla to compile and run with GCC 9.9.2 (actually GCC 6+), once it was compiled, with any optimization, it would crash, usually before finishing drawing the main window. Turned out it was the compiler helpfully optimizing away the memset() statements as they happened before constructors, something I gather is legal but bad practice. Luckily a cross-platform problem. The GCC folks suggested these CXXFLAGS, -flifetime-dse=1 -fno-delete-null-pointer-checks.
Leaves me wondering if other stuff is getting optimized away or even compiler bugs, which do often show up when optimizing.

Dariusz Piatkowski:
Well you guys...I really honestly wanted this to work...but man, a trap every 3 hrs. is just a little too much for me! (FF is what I'm talking about here)

So I'm trying different things now, I downgraded to LIBICU libicu-65.1-2.oc00.pentium4, which now of course kills the new AOO 4.1.11.

The work around for that is to run the 68 version of LIBICU for AOO (so separate set of DLLs) which I think spells trouble!

Does anyone know of a good AOO work-around for the latest LIBICU challenges?

Dave Yeo:
For Firefox, you might want to try downgrading NSS and NSPR4. Could probably put the DLLs in Firefox's program directory too, untested.

Dariusz Piatkowski:
Dave, everyone...


--- Quote from: Dave Yeo on January 11, 2022, 11:12:25 pm ---For Firefox, you might want to try downgrading NSS and NSPR4. Could probably put the DLLs in Firefox's program directory too, untested.

--- End quote ---

Yup, that's the current "last straw" I'm on LOL.

I did downgrade to LIBICU libicu-65.1-2.oc00.pentium4 first, tried that, but crashes continued, at which point in time I re-installed the 68 release and moved the NSS stuff back to the previous level (3.23).

Since I'm doing all this anyways I thought I'd leave NSPR at 4.23 (per previous upgrade from 4.12) just to see if that is a contributing to the end results I'm seeing in any way.

More to follow as time progresses...thanks for the feedback everyone!

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version