Opened 2 years ago

Closed 2 years ago

#162 closed defect (fixed)

TCP/IP Configuration app hangs

Reported by: David McKenna Owned by:
Priority: major Milestone: GA3
Component: general Version: 1.6.0-b24 GA2
Severity: medium Keywords:
Cc:

Description

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.

Change History (8)

comment:1 Changed 2 years ago by David McKenna

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

comment:2 Changed 2 years ago by 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

comment:3 Changed 2 years ago by diver

  • Milestone changed from Enhanced to GA3

comment:4 Changed 2 years ago by dmik

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

comment:5 Changed 2 years ago by 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.

comment:6 Changed 2 years ago by 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.

comment:7 Changed 2 years ago by 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.

comment:8 Changed 2 years ago by dmik

  • Resolution set to fixed
  • Status changed from new to closed

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.

Note: See TracTickets for help on using tickets.