Occasional crashes in libcn0 using ANPM

[DavidMcKenna]

Occasionally, when using ANPM, I get a beep indicating a trap file is being created and ANPM freezes. It can be killed, but the associated python window remains and won't be killed. The computer is then unstable and must be rebooted. The .trp file indicates a crash in libcn0 and I get a POPUPLOG with references to libcn0. Have seen this enough times now I thought it should be reported. Will attach the .trp and POPUPLOG.

0045_01.TRP.txt POPUPLOG.OS2.txt

[dmik]

The TRP file above is pretty much useless as it's a consequence of an earlier crash in PYTHON.EXE. I need TRP files for that one. From what I see there, the guilty part is LIBCx, not LIBCn. Also, please check /@unixroot/var/log/libcx, this dir may contain some useful logs from LIBCx.

[DavidMcKenna]

The only other *.trp file on my system is in the \sys\apps\anpm folder, but is from a week earlier. It looks suspiciously similar to the one uploaded so will upload in case useful. There were 2 logs in the folder you mention from the same time as the crash, so will upload those too.... 0082_01.TRP.txt CUPSD-5e3c585c-0045.log PYTHON-5e3c5857-0078.log

[DavidMcKenna]

BTW - the original *.trp file was in the root of the C: drive with the POPUPLOG...

[dmik]

The last log file from PYTHON is quite useful indeed! It's while PYTHON was running C:\sys\apps\ANPM\scripts\yum_update.py — most lkely your failing case. The failures is LIBCx assertion complaining that DosFreeMem returns error 487 (ERROR_INVALID_ADDRESS) while serving some mmap or may be munmap call (pity you don't have a .TRP from that run). Interesting, I've never seen it here before. Perhaps, some weird mmap usage in PYTHON while running this yum script.

If you can reproduce it, please try to catch the exact sequence of actions as well as the corresponding .LOG and .TRP file (you may see if the two match by PID and date).

[DavidMcKenna]

Well, it turned out to be easier to reproduce then I anticipated. I decided to downgrade an RPM package (bc) in order to have something to upgrade in ANPM, but when the downgraded package was being installed, I got the *.trp creation beep and an error message:

Error: Couldn't fork %post (bc-1.06-1.oc00.pentium4): Interrupted system call.

While contemplating that, I heard another *.trp creation beep. Hit the close button on the error message and a VX-Rexx console appeared with this message:

SYS1808: The process has stopped. The software diagnostic code (exception code) is 009F.

Closed that and ANPM. Tried to open SeaMonkey to report all this, but it wouldn't start, so rebooted. After reboot, I notice in ANPM that there are now 2 versions of bc listed as installed.

Here are the files created from %UNIXROOT: 0045_01.TRP.txt POPUPLOG.OS2.txt

Here is the file created from \sys\apps\ANPM: 00CB_01.TRP.txt

Here are the logs from \var\log\libcx: CUPSD-5e3e916f-0045.log PYTHON-5e3e91a9-00cf.log PYTHON-5e3e915c-00cb.log SEAMONKEY-5e3e9271-00d1.log

[SilvanScherrer]

Could you try the very same with yum. Just to see if it runs or not. As suspect the vx runtime eats memory like hell. Iirc there was/is such a ticket at netlabs

[DavidMcKenna]

OK, I had to clean up the mess by running 'package-cleanup --cleandupes' then 'yum-complete-transaction' 3 times on the command line to get all incomplete transactions completed. Then I ran 'yum update' and got what you see here: Console yum update.txt

A *.trp beep was heard and the command line window would not close and could not be killed. There were these files in %UNIXROOT: 0045_01-2.TRP.txt POPUPLOG-2.OS2.txt

And these in \var\log\libcx: CUPSD-5e3e9fe7-0045.log PYTHON2.7-5e3e9fe0-008f.log

A minute later the WPS self re-started and froze the machine. I rebooted...

[SilvanScherrer]

btw did you never see these issues with older libc? do you have a lot apps autostarted? As for me it looks like some low shared mem or similar.

[DavidMcKenna]

Seems I first noticed this around the time I updated to ArcaOS 5.0.4, but that may be coincidental. Not sure what 'a lot' of apps is, but according to 'Free Shared Mem', after booting I typically have ~272Mbytes of free shared memory. All the tests I did above were done immediately after booting and without starting anything else (other than what is in startup)...

[DavidMcKenna]

While studying one of the PYTHON traps, I noticed this snippet in the 'DLL's accessible from this process' section:

SQLITE30 07/15/2019 12:15:26 702,332 C:\USR\LIB\SQLITE30.DLL SOFTOKN3 12/03/2019 11:11:01 123,940 C:\USR\LIB\SOFTOKN3.DLL PLDS4 11/14/2019 02:50:12 4,089 C:\USR\LIB\PLDS4.DLL PLC4 11/14/2019 02:50:12 6,341 C:\USR\LIB\PLC4.DLL NSSUTIL3 12/03/2019 11:11:01 82,790 C:\USR\LIB\NSSUTIL3.DLL NSS3 12/03/2019 11:11:01 564,943 C:\USR\LIB\NSS3.DLL LUA53 04/05/2017 20:46:17 123,732 C:\USR\LIB\LUA53.DLL POPT 12/08/2015 10:08:08 20,483 C:\USR\LIB\POPT.DLL DB48 04/13/2017 11:06:13 879,611 C:\USR\LIB\DB48.DLL SSP0 01/15/2020 07:50:10 5,664 C:\USR\LIB\SSP0.DLL RPM7 06/21/2019 10:40:28 241,425 C:\USR\LIB\RPM7.DLL RPMIO7 06/21/2019 10:40:28 81,586 C:\USR\LIB\RPMIO7.DLL _RPM 06/21/2019 10:40:28 52,628 C:\USR\LIB\PYTHON2.7\SITE-PACKAGES\RPM_RPM.DLL TIME 01/23/2019 02:53:04 7,747 C:\USR\LIB\PYTHON2.7\LIB-DYNLOAD\TIME.PYD PYTHON27 01/23/2019 02:56:12 947,445 C:\USR\LIB\PYTHON27.DLL NSPR4 08/17/2019 21:07:27 137,493 C:\PROGRAMS\SEAMONKEY\NSPR4.DLL

Not clear why NSPR4.dll from SeaMonkey is being used - it is not on the LIBPATH, but I do use SMTURBO to load SeaMonkey's DLL's, including NSPR4. Why the NSS and SQLITE DLL's from SeaMonkey are not also used (they are also loaded by SMTURBO) is a mystery to me. So decided to copy NSPR4.dll from C:\usr\lib into the SeaMonkey directory. Doesn't seem to negatively affect SeaMonkey, and for the last month I haven't had any issues running ANPM.

[dryeo]

On 03/14/20 04:57 PM, DavidMcKenna wrote:

Not clear why NSPR4.dll from SeaMonkey is being used - it is not on the LIBPATH, but I do use SMTURBO to load SeaMonkey's DLL's, including NSPR4.

Strange as both SM and smturbo set BEGINLIBPATH and LIBPATHSTRICT.

[SilvanScherrer]

Im closing it as a seamonkey issue then.