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

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Arno J. Klaassen-2

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

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-java
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

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

John Baldwin
On Saturday 26 November 2005 08:50 pm, Arno J. Klaassen wrote:

> 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

FYI, there is a 'linux-kdump' in ports that parses the syscalls from a ktrace
on a linux binary.  You can use that to make sure your mapping of 175 to
sigprocmask() is correct.

--
John Baldwin <[hidden email]>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-java
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

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

Michael VInce-2
In reply to this post by Arno J. Klaassen-2
Which linux port are you using?

I have had beta versions of OpenOffice2 for linux lock up my FreeBSD
amd64 desktop, but once I started using OO2 release for linux the
lockups went away. I also started using the Suse port.
/usr/ports/emulators/linux_base-suse-9.2/

OVERRIDE_LINUX_BASE_PORT=suse-9.2
in make.conf


Arno J. Klaassen wrote:

>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
>
>
>  
>

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-java
To unsubscribe, send any mail to "[hidden email]"