Date: Tue, 29 May 2012 14:02:20 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Kustaa Nyholm <Kustaa.Nyholm@planmeca.com> Cc: "freebsd-java@freebsd.org" <freebsd-java@freebsd.org> Subject: Re: tcgetattr hangs Message-ID: <20120529110220.GI2358@deviant.kiev.zoral.com.ua> In-Reply-To: <CBEA8254.385E5%kustaa.nyholm@planmeca.com> References: <CBEA8254.385E5%kustaa.nyholm@planmeca.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--lE3gG894P96VuAc/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 29, 2012 at 01:40:36PM +0300, Kustaa Nyholm wrote: > Hi, >=20 > this maybe wrong list but it was suggested I try my luck here. >=20 > MY feeling is that this NOT a Java issue per se but here goes. >=20 > I'm the developer of PureJavaComm (PJC) , a pure Java serial port access > library that runs on Mac OS X, Linux, Windows and soon I hope on > FreeBSD. I'm co-operating with someone to port the library to > FreeBSD but we have run into mysterious problem that has defeated > all our debugging efforts. >=20 > PJC can be found at: >=20 > https://github.com/nyholku/purejavacomm >=20 > Some background. PJC uses JNA which is a library to access C-code > APIs from Java by writing Java classes that JNA automatically > turns in to standard C calls. >=20 > The C functions we are using are very simple and few, here is the complete > list to put you into the picture (btw, this is Java): >=20 > int errno(); > int fcntl(int fd, int cmd, int arg); int cfgetispeed(Termios termios); > int cfgetospeed(Termios termios); > int setspeed(int fd, int speed); > int cfsetispeed(Termios termios, int speed); > int cfsetospeed(Termios termios, int speed) > int tcflush(int fd, int b); > int tcdrain(int fd); > void cfmakeraw(Termios termios); > int tcgetattr(int fd, Termios termios); > int tcsetattr(int fd, int cmd, Termios termios); int tcsendbreak(int fd, > int duration); > int open(String s, int t); int close(int fd); > int write(int fd, byte[] buffer, int len); > int read(int fd, byte[] buffer, int len); > int ioctl(int fd, int cmd, int[] data); > int select(int n, FDSet read, FDSet write, FDSet error, TimeVal timeout); >=20 >=20 >=20 > So far we have been able to run PJC testsuite in FreeBSD 32 bit Intel with > no problems. >=20 > Now however, on FreeBSD 64 bit AMD our test set hangs in a call to > tcgetattr() > in the third test case in our test suite. >=20 > The first test opens a port and wiggles some control lines, then closes > the port. > The second test sends and receives a some hundreds of messages using a > background > thread and select(). This is the test that is causing problem further down > the line. > After this test the next test (regardless what it is) hangs in a call to > tcgetattr() > after successfully opening the port. >=20 > So how can tcgetattr() hang??? >=20 > I found one reference to a similar problem but no solution: >=20 > http://freebsd.1045724.n5.nabble.com/Re-cups-bugs-tcgetattr-causes-lockup= -i > n-USB-backend-on-FreeBSD6-STABLE-td3950285.html >=20 > Here is a piece of our debug log that shows the calls from Java to the > native > API showing the end of the successful Test2 and the hang at the beginning > of Test3: >=20 > log: > select(9,[8],[],[],jtermios.TimeVal@6f507fb2) > .................................. OK average speed log: < > select(9,[],[],[],jtermios.TimeVal@6f507fb2) =3D> 0 > log: > select(9,[8],[],[],jtermios.TimeVal@6f507fb2) > 18241 b/sec at baud rate 19200 > log: > fcntl(8, 3, 0) > log: < fcntl(8, 3, 0) =3D> 2 > log: > fcntl(8, 4, 6) > log: < fcntl(8, 4, 6) =3D> 0 > log: > close(8) > log: < close(8) =3D> 0 > Test3 - transmit all characters log: < > select(9,[8],[],[],jtermios.TimeVal@6f507fb2) =3D> -1 > log: > open('cuau0',00008006) > log: < open('cuau0',00008006) =3D> 8 > log: > close(8) > log: < close(8) =3D> 0 > log: > open('cuau0',00008006) > log: < open('cuau0',00008006) =3D> 8 > log: > fcntl(8, 3, 0) > log: < fcntl(8, 3, 0) =3D> 6 > log: > fcntl(8, 4, 2) > log: < fcntl(8, 4, 2) =3D> 0 > log: > tcgetattr(8,jtermios.Termios@5a77a7f9) >=20 >=20 > All comments welcome. Verify that the thread indeed hang in ioctl, executed on the right file descriptor and TIOCGETA ioctl command. You may use ktrace(1) or truss(1) for this. If ioctl(TIOCGETA) is indeed what was called, then look at the in-kernel backtrace of the hung thread with procstat -kk <pid> command. --lE3gG894P96VuAc/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk/ErLwACgkQC3+MBN1Mb4jwqgCgr3FBoSULFVhfdctM6w8pl2+D LSsAoJJJnd0kOLQmn0jgEaQcNGMAhgdD =3nNE -----END PGP SIGNATURE----- --lE3gG894P96VuAc/--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120529110220.GI2358>