TCP/IP Configuration app hangs

[David McKenna]

Installed Odin 0.8.4 using YUM and copied new Java into \Programs\Java6. REM'd out 'SET CLASSPATH', 'SET JAVA_HOME', and SET JAVA_HIGH_MEM' lines in CONFIG.SYS. Also changed the JAVA142 entry in 'SET PATH' to JAVA6.

TCP/IP configuration app starts up fine and shuts down fine if I make no change. If I make any change, then when it goes to write the change during shutdown, the app hangs with a dialog saying 'saving' and cannot be closed or killed. I have to reboot to clear the dialog. The change is not made.

[David McKenna]

I should mention I could not kill Java in this situation using TOP either.

[gerrit]

Hi,

My experience with issue mentioned above is about the same, except that the TCP/IP configuration app doesn't hang after making a change. Furthermore changes made are not being saved and after starting the TCP/IP java app everything is as it was before.

Intermezzo
==========

• Installed ODIN 0.84 using WarpIN
• REM'd out all old JAVA statements in the config.sys, except SET JAVA_HIGH_MEM
• Changed the JAVA SET PATH and LIBPATH settings in config.sys to the new Java6 program directory

BR
Gerrit Schoenmaker
Pres. Dutch OS/2 & eCS usergroup

[dmik]

I can confirm that but I don't see why yet.

[dmik]

I see that TCPOOCS.DLL throws some strange exception (0x20000) when you ask it to save the settings and this causes the application to exit early.

This may be related to the SEH emulation (to the fact that we change FS and alter the OS/2 exception chain). Checking.

[dmik]

Yes, that must be the case. The problem is more global though. When the Win32 GetProcAddress API is called, it is expected that the function it returns is a Win32 function WRT SEH and other context-related things. In particular, it means that FS should point to the Wn32 TEB, not to the OS/2 TEB.

However, if GetProcAddress is called against a true OS/2 DLL (i.e. not a true Win32 DLL and not an OS/2 DLL that emulates Win32 with Odin), the function it returns will expect the OS/2 context. And this is the case for TCPOOCS.DLL (which was written for the true OS/2 Java implementation). There may be some more cases when it makes difference, not only WRT Java.

So I think we should somehow detect if the DLL addressed by GetProcAddress is a real OS/2 DLL not related to Odin and in this case create a wrapper that will perform the necessary context switch and return the address of this wrapper instead of the real function.

This detection may be e.g. based on a fact that the given DLL imports some of the Odin DLLs (KERNEL32 etc). I will try this approach.

[dmik]

Hmm, I realized that just creating a DLL entry wrapper is strictly speaking not enough: we'd also need to wrap all the JNIEnv entries to perform the reverse context switch (OS/2->Win32->OS/2) -- i.e. basically what Innotek did with their j2win.dll for Java 1.4.

I've got a better idea: I will try to get rid of using the Win32 context (i.e. storing Win32 TEB in FS) in OpenJDK at all -- since we control everything at the source level (as opposed to Innotek Java), this should be doable. This way, we will not need any wrappers at all.

[dmik]

The idea with disabling the context switch worked (see ​http://svn.netlabs.org/odin32/ticket/82 for details). The settings can now be successfully saved.