Unzip Version 6.0 hangs when booting to a commandline

[Dave Yeo]

Here's a build using the old EMX build flags, so no libcx or libbz2, to test.
Edit: add wildcard support

[Lars]

Thanks Dave,

but your test build hangs in the very same way. What I now found out: if it hangs and if I hit Ctrl-C, after about 20 seconds or so, the program will be terminated. This however only works once. If I try a second time, the system hangs solid.

What I can also observe is quite some disk activity if I hit Ctrl-C for the first time (until the program finally terminates). I'll have to check if POPUPLOG.OS2 is written ...

[Andi B.]

Lars, do you have any chance to start it in OpenWatcom Debugger (wd.exe)?

[Dave Yeo]

Well. at least that means it is a libcn problem. I could build a debug copy of unzip if you think it would help.
Perhaps better would be to try the logging version of libcn, @unixroot/usr/lib/log/libcn0.dll I believe. You have to swap it with the usual libcn and reboot, libpathstrict does not work with libc. See https://trac.netlabs.org/libc/wiki/LibcLogging.
@Andi, the OpenWatcom debugger won't work, need to use a native debugger.

[Andi B.]

...
@Andi, the OpenWatcom debugger won't work, need to use a native debugger.

I thought I had it up and running long time ago. But maybe my memory is wrong.

What I did some time ago was booting up to command line with netbios drivers enabled and the watcom debug/netbios driver and remote debugged a cli program from another machine with wdw. I saw (wdw told me) that my cli program wanted to call a ..... (?) function which wasn't available when booted up only to cli without pmshell.

[Dave Yeo]

Perhaps it was a program compiled with OW. Wlink was patched by Knut years back to support, I think it's HLL debug data, now merged into OW.
GCC, you need -g for debug data and link with -Zomf, then idebug etc will work. At least sd86 will allow remote debugging over tcpip, not sure about the other IBM debuggers and whether they support remote debugging.

[Lars]

Well. at least that means it is a libcn problem. I could build a debug copy of unzip if you think it would help.
Perhaps better would be to try the logging version of libcn, @unixroot/usr/lib/log/libcn0.dll I believe. You have to swap it with the usual libcn and reboot, libpathstrict does not work with libc. See https://trac.netlabs.org/libc/wiki/LibcLogging.
@Andi, the OpenWatcom debugger won't work, need to use a native debugger.

Hi Dave,

thanks for the hint. I now did as you suggested and I get the attached as a result. The system hung solid so the last log entry was the last thing that was logged. I am beginning to suspect it is because KLIBCCFG.DLL pulls in so many things, for example FFST (I had a look at KLIBCCFG.DLL with PM DLLTree).

And here comes the biggest problem: _kLIBCInitPath in KLIBCCFG.DLL will likely read its transformed paths from INI file %ETC%\klibccfg.ini where I suspect, it uses the profile API calls. I think, those will only work if PM is up and running.

In short: every program built with kLIBC depends on PM being loaded. I tested this by setting RUNWORKPLACE to cmd.exe (therefore only booting with PM but without the WPS) and then running unzip.exe from that commandline and that worked ok.

The solution would be to replace the profile API calls in KLIBCCFG.DLL against calls that directly work on the binary .INI files. I think XWorkplace also does that.

[Dave Yeo]

Makes sense that is why it is failing hard. Guess an issue should be raised at Bitwise's Github, not good having everything built against libc dependent on the PMShell.

[Lars]

I cannot find the source code for klibccfg.dll. I'll contact Silvan.

[Lars]

Answer Silvan: the KLIBCCFG sources are lost. End of game.

[Lars]

A solution to avoid a system hang is to remove the environment var statement:

set LIBC_HOOK_DLLS=....

from config.x. That at least will allow to hit Ctrl-C to stop the process instead of hanging the whole system.

[Lars]

I now have an idea on how to solve this problem. Will take some trial and error and some time. NO guarantee that it will work but it's worth giving a try.

[Dariusz Piatkowski]

Hey Martin,

...For what I see on the F2 boot the %LIBPATH% is not recognized, but the config files looks fine. Is there any elegant way to see full the enviroment variables on the command line (image LIBPATH_F2.png )?...

Dave Yeo already gave the much bigger answer, but otherwise, if you want to look at each individual ENV variable you can do this at CLI:

Code Select Expand


echo %PATH%


[Dave Yeo]

Code Select Expand


echo %PATH%


Easier,

Code Select Expand


set PATH

Make sure you don't add an equals sign

[Alex Taylor]

Current versions of ArcaOS don't use klibccfg.dll at all.  It doesn't load it, TTBOMK doesn't even ship with it.

(It instead provides a replacement called prewrite.dll which provides the path remapping feature to the limit extent that it's needed/useful.)