quest for help on a linux emul problem (source unknown)

[Arno J. Klaassen]

Hello,


I try to get a commercial linux32 package to work on amd64;
this package includes it's own binary distrib of some
linux-jdk1.3.1 and works OK on i386 (RELENG_5 and RELENG_6) but
hangs on amd64-RELENG_6 (though it did work on a couple
of months old amd64-RELENG-5, but I do not any longer have such
a box around ... ).

I write this email in the hope someone can put me on the right
track to nail down this problem :

when I do a ktrace on i386 I get :

  CALL  mincore(0xbfbfc480,0)
  RET   mincore 0
  CALL  #175(0,0,0xbfbfc2b4,0x8)
  RET   #175 0
  CALL  #175(0x1,0xbfbfc3b8,0xbfbfc338,0x8)
  RET   #175 0
  CALL  mincore(0xbfbfc290,0)
  RET   mincore 0
  CALL  getdomainname(0xbfbfc288,0)
  RET   getdomainname 0

then some dozens of :

  CALL  #175(0x2,0xbfbfc338,0,0x8)
  RET   #175 0
  CALL  mincore(0xbfbfc480,0)
  RET   mincore 0
  CALL  #175(0,0,0xbfbfc2b4,0x8)
  RET   #175 0
  CALL  #175(0x1,0xbfbfc3b8,0xbfbfc338,0x8)
  RET   #175 0
  CALL  mincore(0xbfbfc290,0)
  RET   mincore 0
  CALL  getdomainname(0xbfbfc288,0)
  RET   getdomainname 0


and finally :

  CALL  #175(0x2,0xbfbfc338,0,0x8)
  RET   #175 0
  CALL  write(0xb,0x83189e8,0x18)
  GIO   fd 11 wrote 24 bytes


On amd64-RELENG_6 it eternally loops in phase2 and never
reaches the 'finally'.

Iff I understand correctly (far from sure!) and correct
for different syscall-numbers, I get :

ask-for-initing-something {
  gettimeofday()
  sigprocmask(SIG_BLOCK,..)
  sigprocmask(SIG_UNBLOCK,..)
  gettimeofday()
  nanosleep()
}

while-not-OK {
  sigprocmask(SIG_SETMASK,..)
  gettimeofday()
  sigprocmask(SIG_BLOCK,..)
  sigprocmask(SIG_UNBLOCK,..)
  gettimeofday()
  nanosleep()
}

OK! {
  sigprocmask(SIG_SETMASK,..)
  continue()
}


Since the program works OK in terminal mode, the problem
very probably is in the jdk-execution. I re-downloaded the
jdk13 sources and found that only at two places sigprocmask() is
called with SIG_UNBLOCK as argument, and one of them only
seems to serve the purpose of a work-around :

 * a workaround for the preemptive-close
 * problem on Linux (bug #4344135); A thread currently waiting in
 * a I/O operation will not wake up if one the file involved
 * is actually closed (last close - the file is no longer accessible,
 * but the thread is still waiting in the kernel).

NB, this is a linux-jdk-1.3.0 problem, solved in linux-jdk-1.3.1,
so "an sich" not involved in my problem, but the idea of a thread
not waking up or signal not getting correctly delivered seems
plausible to my simple end-user mind.

once again, if this kind of pseudo-code sounds familiar to someone, please
give me some hints which way to go to write a simple test-program
to pinpoint the problem.
Thank you very much for your time anyway.

Regards, Arno


-- 

  Arno J. Klaassen

  SCITO S.A.
  8 rue des Haies
  F-75020 Paris, France
  http://scito.com