From cowwoc at bbs.darktech.org Wed Apr 1 22:05:13 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Thu, 02 Apr 2009 00:05:13 -0400 Subject: [Rxtx] Windows 64-bit support? Message-ID: <49D43979.4050702@bbs.darktech.org> Hi, I'd like to run RXTX under the Windows 64-bit JVM. Are there plans to release an official 64-bit version anytime soon? Gili From bill7007 at gmail.com Thu Apr 2 16:01:17 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Thu, 2 Apr 2009 18:01:17 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel Message-ID: Hi, I have an rxtx serial application that used to work reliably until I had to move it to newer hardware and kernel. Now, the application sometimes hangs near first port use. When it does hang, it can be released by starting a second copy of the application which is locked out of the ports but does release the first process. Upgraded from rxtx-2.1-7-r2 to rxtx-2.2pre2 but still hangs. Tried to rebuild on the target machine and ran into the 'UTS_RELEASE' undeclared problem so holding on that approach. Recompiled OK on a 2.6.9-42.0.3.ELsmp system. Debug messages were turned on using: "./configure --enable-DEBUG" and modified RXTXPort.java with: "debug = true;" "z = new Zystem(Zystem.PRINT_MODE);" Below is capture of the application with debugging enabled. It show the application hang point, and the second application's printout at the release point. (pre3 is the locally modified version of pre2) Any suggestions on how to pin this down further? Thanks, +BillJ $ java -version java version "1.5.0_06" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05) Java HotSpot(TM) Client VM (build 1.5.0_06-b05, mixed mode, sharing) $ uname -a Linux qms4 2.6.18-92.1.6.el5 #1 SMP Wed Jun 25 13:49:24 EDT 2008 i686 i686 i386 GNU/Linux ***CAPTURE: [qms at qms4 ~]$ ./qms/ScriptFiles/startup.sh Thu Apr 02 13:35:45 EDT 2009:Setting Log File to:/home/qms/qms/QMS.log Thu Apr 02 13:35:45 EDT 2009:TSettings.HandleIni:ReUsing Ini file:/home/qms/qms/qms.properties WARNING: RXTX Version mismatch Jar version = RXTX-2.2pre2 native lib Version = RXTX-2.2pre3 fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB2 fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB1 fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB0 fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile RXTXPort {} RXTX WARNING: This library was compiled to run with OS release 2.4.20 and you are currently running OS release 2.6.18-92.1.6.el5. In some cases this can be a problem. Try recompiling RXTX if you notice strange behavior. If you just compiled RXTX make sure /usr/include/linux is a symbolic link to the include files that came with the kernel source and not an older copy. press enter to continue RXTXPort:RXTXPort(/dev/ttyUSB2) called fhs_lock: creating lockfile: 10127 open: locking worked for /dev/ttyUSB2 open: fd returned is 8 RXTXPort:MontitorThread:MonitorThread() RXTXPort:MontitorThread:run() has_line_status_register_acess: Port does not support TIOCSERGETLSR init_threads: get eis init_threads: set eis init_threads: stop RXTXPort:RXTXPort(/dev/ttyUSB2) returns with fd = 8 RXTXPort:setSerialPortParams(38400 8 1 0) called RXTXPort:setSerialPortParams(38400 8 1 0) returning RXTXPort:getInputStream() called and returning Thu Apr 02 13:36:02 EDT 2009:TSerial[22]:Using Port:/dev/ttyUSB2 RXTXPort:getOutputStream() called and returning Thu Apr 02 13:36:02 EDT 2009:TSerial[22].Transmit:TN Entering RXTXPort:SerialOutputStream:write(4) writeArray() Leaving RXTXPort:SerialOutputStream:write(4) RXTXPort:SerialOutputStream:flush() enter RXTXPort:SerialOutputStream:flush() leave Thu Apr 02 13:36:02 EDT 2009:TSerial[22].Transmit:RV Entering RXTXPort:SerialOutputStream:write(4) writeArray() Leaving RXTXPort:SerialOutputStream:write(4) RXTXPort:SerialOutputStream:flush() enter RXTXPort:SerialInputStream:read(8192 0 8192) called ***FIRST PROCESS HANGS HERE ***THEN PROCEEDS AFTER SECOND PROCESS STARTS RXTXPort:SerialOutputStream:flush() leave Thu Apr 02 13:41:29 EDT 2009:TSerial[22].Transmit:IH9 Entering RXTXPort:SerialOutputStream:write(5) writeArray() Leaving RXTXPort:SerialOutputStream:write(5) RXTXPort:SerialOutputStream:flush() enter RXTXPort:SerialOutputStream:flush() leave Thu Apr 02 13:41:29 EDT 2009:TSerial[22].Transmit:IL11 ***END CAPTURE ***CAPTURE SECOND PROCESS FAILS OPEN [qms at qms4 ~]$ ./qms/ScriptFiles/startup.sh Thu Apr 02 13:41:27 EDT 2009:Setting Log File to:/home/qms/qms/QMS.log Thu Apr 02 13:41:27 EDT 2009:TSettings.HandleIni:ReUsing Ini file:/home/qms/qms/qms.properties WARNING: RXTX Version mismatch Jar version = RXTX-2.2pre2 native lib Version = RXTX-2.2pre3 fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB2: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB1: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB0: File exists fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB2: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB1: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB0: File exists fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile Thu Apr 02 13:41:30 EDT 2009:TIOBoard: java.io.IOException: java.io.IOException: TSerial[22]: Open Failed ***END CAPTURE -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090402/c66f8d70/attachment.html From netbeans at gatworks.com Thu Apr 2 17:15:04 2009 From: netbeans at gatworks.com (U. George) Date: Thu, 02 Apr 2009 19:15:04 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: Message-ID: <49D546F8.20807@gatworks.com> > "z = new Zystem(Zystem.PRINT_MODE);" > Below is capture of the application with debugging enabled. It show > the application hang point, and the second application's printout at the > release point. (pre3 is the locally modified version of pre2) > Any suggestions on how to pin this down further? > Thanks, > +BillJ When perceived runability is hung, try a ^\ ( control \) on console. This gets the JVM to dump the stacks of all the java threads. If you know the thread that is stuck, then u can see what java statement its stuck at. From tjarvi at qbang.org Thu Apr 2 19:25:17 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 2 Apr 2009 19:25:17 -0600 (MDT) Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: <49D546F8.20807@gatworks.com> References: <49D546F8.20807@gatworks.com> Message-ID: On Thu, 2 Apr 2009, U. George wrote: >> "z = new Zystem(Zystem.PRINT_MODE);" >> Below is capture of the application with debugging enabled. It show >> the application hang point, and the second application's printout at the >> release point. (pre3 is the locally modified version of pre2) >> Any suggestions on how to pin this down further? >> Thanks, >> +BillJ > > When perceived runability is hung, try a ^\ ( control \) on console. > This gets the JVM to dump the stacks of all the java threads. > If you know the thread that is stuck, then u can see what java statement > its stuck at. I've also noticed some linux systems hanging with open/read/write and saw kacpid storms. I need to look at it more but did observe kacpid consuming a core and not returning to a normal state for a significant period of time. It was easy to observe from top sorted by CPU usage. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Apr 2 19:26:18 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 2 Apr 2009 19:26:18 -0600 (MDT) Subject: [Rxtx] Windows 64-bit support? In-Reply-To: <49D43979.4050702@bbs.darktech.org> References: <49D43979.4050702@bbs.darktech.org> Message-ID: On Thu, 2 Apr 2009, cowwoc wrote: > Hi, > > I'd like to run RXTX under the Windows 64-bit JVM. Are there plans > to release an official 64-bit version anytime soon? > It is in the prerelease and will be in the final release. I'm pushing it through as fast as I can in my free time. -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Thu Apr 2 22:57:34 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Fri, 03 Apr 2009 00:57:34 -0400 Subject: [Rxtx] Missing documentation In-Reply-To: References: <49D43979.4050702@bbs.darktech.org> Message-ID: <49D5973E.4050400@bbs.darktech.org> Hi, I noticed that RXTX 2.1 drops javax.comm support in favor of gnu.io. I have one major problem with this: the gui.io.* documentation is very poor. Many classes and methods have no Javadoc at all which makes them difficult to use. Please fix this for the final release. Thank you, Gili From alex.sas at freemail.hu Fri Apr 3 01:36:54 2009 From: alex.sas at freemail.hu (Sas Alex) Date: Fri, 3 Apr 2009 09:36:54 +0200 (CEST) Subject: [Rxtx] Serial port false reads Message-ID: Hi all, On Windows XP, using rxtx-2.1-7-r2 I have a program communicating on a serial line like the following (excerpt): { os.write(command); os.flush(); // Thread.sleep(period); // read response while(is.available() > 0) { is.read() } } If there is a sleep between the os.flush and the reading cycle the correct answer is received. Otherwise (sometimes) there are extra, erronous characters at the beginning of the answer, but the correct answer (according to the protocol) also arrives, afterwards. Is this a normal behaviour, one should wait before the read? If yes, is there a way to determine the minimum amount of time to wait for? Serial port params are: 9600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE. Thank you in advance, Alex ________________________________________________________ El?foglal?si akci? meghosszabb?tva! Korfui ?d?l?s m?r 56.910 Ft-t?l. http://www.budavartours.hu/gorogorszag/?utm_campaign=origo&utm_source=freemail_kimeno_090403&utm_medium=ct&utm_content=korfu_elofoglalasi_akcio#reg_Korfu -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090403/8f3650ea/attachment.html From cowwoc at bbs.darktech.org Wed Apr 1 22:05:13 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Thu, 02 Apr 2009 00:05:13 -0400 Subject: [Rxtx] Windows 64-bit support? Message-ID: <49D43979.4050702@bbs.darktech.org> Hi, I'd like to run RXTX under the Windows 64-bit JVM. Are there plans to release an official 64-bit version anytime soon? Gili From bill7007 at gmail.com Thu Apr 2 16:01:17 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Thu, 2 Apr 2009 18:01:17 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel Message-ID: Hi, I have an rxtx serial application that used to work reliably until I had to move it to newer hardware and kernel. Now, the application sometimes hangs near first port use. When it does hang, it can be released by starting a second copy of the application which is locked out of the ports but does release the first process. Upgraded from rxtx-2.1-7-r2 to rxtx-2.2pre2 but still hangs. Tried to rebuild on the target machine and ran into the 'UTS_RELEASE' undeclared problem so holding on that approach. Recompiled OK on a 2.6.9-42.0.3.ELsmp system. Debug messages were turned on using: "./configure --enable-DEBUG" and modified RXTXPort.java with: "debug = true;" "z = new Zystem(Zystem.PRINT_MODE);" Below is capture of the application with debugging enabled. It show the application hang point, and the second application's printout at the release point. (pre3 is the locally modified version of pre2) Any suggestions on how to pin this down further? Thanks, +BillJ $ java -version java version "1.5.0_06" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05) Java HotSpot(TM) Client VM (build 1.5.0_06-b05, mixed mode, sharing) $ uname -a Linux qms4 2.6.18-92.1.6.el5 #1 SMP Wed Jun 25 13:49:24 EDT 2008 i686 i686 i386 GNU/Linux ***CAPTURE: [qms at qms4 ~]$ ./qms/ScriptFiles/startup.sh Thu Apr 02 13:35:45 EDT 2009:Setting Log File to:/home/qms/qms/QMS.log Thu Apr 02 13:35:45 EDT 2009:TSettings.HandleIni:ReUsing Ini file:/home/qms/qms/qms.properties WARNING: RXTX Version mismatch Jar version = RXTX-2.2pre2 native lib Version = RXTX-2.2pre3 fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB2 fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB1 fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB0 fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile RXTXPort {} RXTX WARNING: This library was compiled to run with OS release 2.4.20 and you are currently running OS release 2.6.18-92.1.6.el5. In some cases this can be a problem. Try recompiling RXTX if you notice strange behavior. If you just compiled RXTX make sure /usr/include/linux is a symbolic link to the include files that came with the kernel source and not an older copy. press enter to continue RXTXPort:RXTXPort(/dev/ttyUSB2) called fhs_lock: creating lockfile: 10127 open: locking worked for /dev/ttyUSB2 open: fd returned is 8 RXTXPort:MontitorThread:MonitorThread() RXTXPort:MontitorThread:run() has_line_status_register_acess: Port does not support TIOCSERGETLSR init_threads: get eis init_threads: set eis init_threads: stop RXTXPort:RXTXPort(/dev/ttyUSB2) returns with fd = 8 RXTXPort:setSerialPortParams(38400 8 1 0) called RXTXPort:setSerialPortParams(38400 8 1 0) returning RXTXPort:getInputStream() called and returning Thu Apr 02 13:36:02 EDT 2009:TSerial[22]:Using Port:/dev/ttyUSB2 RXTXPort:getOutputStream() called and returning Thu Apr 02 13:36:02 EDT 2009:TSerial[22].Transmit:TN Entering RXTXPort:SerialOutputStream:write(4) writeArray() Leaving RXTXPort:SerialOutputStream:write(4) RXTXPort:SerialOutputStream:flush() enter RXTXPort:SerialOutputStream:flush() leave Thu Apr 02 13:36:02 EDT 2009:TSerial[22].Transmit:RV Entering RXTXPort:SerialOutputStream:write(4) writeArray() Leaving RXTXPort:SerialOutputStream:write(4) RXTXPort:SerialOutputStream:flush() enter RXTXPort:SerialInputStream:read(8192 0 8192) called ***FIRST PROCESS HANGS HERE ***THEN PROCEEDS AFTER SECOND PROCESS STARTS RXTXPort:SerialOutputStream:flush() leave Thu Apr 02 13:41:29 EDT 2009:TSerial[22].Transmit:IH9 Entering RXTXPort:SerialOutputStream:write(5) writeArray() Leaving RXTXPort:SerialOutputStream:write(5) RXTXPort:SerialOutputStream:flush() enter RXTXPort:SerialOutputStream:flush() leave Thu Apr 02 13:41:29 EDT 2009:TSerial[22].Transmit:IL11 ***END CAPTURE ***CAPTURE SECOND PROCESS FAILS OPEN [qms at qms4 ~]$ ./qms/ScriptFiles/startup.sh Thu Apr 02 13:41:27 EDT 2009:Setting Log File to:/home/qms/qms/QMS.log Thu Apr 02 13:41:27 EDT 2009:TSettings.HandleIni:ReUsing Ini file:/home/qms/qms/qms.properties WARNING: RXTX Version mismatch Jar version = RXTX-2.2pre2 native lib Version = RXTX-2.2pre3 fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB2: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB1: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB0: File exists fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB2: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB1: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB0: File exists fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile Thu Apr 02 13:41:30 EDT 2009:TIOBoard: java.io.IOException: java.io.IOException: TSerial[22]: Open Failed ***END CAPTURE -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090402/c66f8d70/attachment-0001.html From netbeans at gatworks.com Thu Apr 2 17:15:04 2009 From: netbeans at gatworks.com (U. George) Date: Thu, 02 Apr 2009 19:15:04 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: Message-ID: <49D546F8.20807@gatworks.com> > "z = new Zystem(Zystem.PRINT_MODE);" > Below is capture of the application with debugging enabled. It show > the application hang point, and the second application's printout at the > release point. (pre3 is the locally modified version of pre2) > Any suggestions on how to pin this down further? > Thanks, > +BillJ When perceived runability is hung, try a ^\ ( control \) on console. This gets the JVM to dump the stacks of all the java threads. If you know the thread that is stuck, then u can see what java statement its stuck at. From tjarvi at qbang.org Thu Apr 2 19:25:17 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 2 Apr 2009 19:25:17 -0600 (MDT) Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: <49D546F8.20807@gatworks.com> References: <49D546F8.20807@gatworks.com> Message-ID: On Thu, 2 Apr 2009, U. George wrote: >> "z = new Zystem(Zystem.PRINT_MODE);" >> Below is capture of the application with debugging enabled. It show >> the application hang point, and the second application's printout at the >> release point. (pre3 is the locally modified version of pre2) >> Any suggestions on how to pin this down further? >> Thanks, >> +BillJ > > When perceived runability is hung, try a ^\ ( control \) on console. > This gets the JVM to dump the stacks of all the java threads. > If you know the thread that is stuck, then u can see what java statement > its stuck at. I've also noticed some linux systems hanging with open/read/write and saw kacpid storms. I need to look at it more but did observe kacpid consuming a core and not returning to a normal state for a significant period of time. It was easy to observe from top sorted by CPU usage. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Apr 2 19:26:18 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 2 Apr 2009 19:26:18 -0600 (MDT) Subject: [Rxtx] Windows 64-bit support? In-Reply-To: <49D43979.4050702@bbs.darktech.org> References: <49D43979.4050702@bbs.darktech.org> Message-ID: On Thu, 2 Apr 2009, cowwoc wrote: > Hi, > > I'd like to run RXTX under the Windows 64-bit JVM. Are there plans > to release an official 64-bit version anytime soon? > It is in the prerelease and will be in the final release. I'm pushing it through as fast as I can in my free time. -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Thu Apr 2 22:57:34 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Fri, 03 Apr 2009 00:57:34 -0400 Subject: [Rxtx] Missing documentation In-Reply-To: References: <49D43979.4050702@bbs.darktech.org> Message-ID: <49D5973E.4050400@bbs.darktech.org> Hi, I noticed that RXTX 2.1 drops javax.comm support in favor of gnu.io. I have one major problem with this: the gui.io.* documentation is very poor. Many classes and methods have no Javadoc at all which makes them difficult to use. Please fix this for the final release. Thank you, Gili From alex.sas at freemail.hu Fri Apr 3 01:36:54 2009 From: alex.sas at freemail.hu (Sas Alex) Date: Fri, 3 Apr 2009 09:36:54 +0200 (CEST) Subject: [Rxtx] Serial port false reads Message-ID: Hi all, On Windows XP, using rxtx-2.1-7-r2 I have a program communicating on a serial line like the following (excerpt): { os.write(command); os.flush(); // Thread.sleep(period); // read response while(is.available() > 0) { is.read() } } If there is a sleep between the os.flush and the reading cycle the correct answer is received. Otherwise (sometimes) there are extra, erronous characters at the beginning of the answer, but the correct answer (according to the protocol) also arrives, afterwards. Is this a normal behaviour, one should wait before the read? If yes, is there a way to determine the minimum amount of time to wait for? Serial port params are: 9600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE. Thank you in advance, Alex ________________________________________________________ El?foglal?si akci? meghosszabb?tva! Korfui ?d?l?s m?r 56.910 Ft-t?l. http://www.budavartours.hu/gorogorszag/?utm_campaign=origo&utm_source=freemail_kimeno_090403&utm_medium=ct&utm_content=korfu_elofoglalasi_akcio#reg_Korfu -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090403/8f3650ea/attachment-0001.html From bill7007 at gmail.com Fri Apr 3 16:15:30 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Fri, 3 Apr 2009 18:15:30 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: <49D546F8.20807@gatworks.com> Message-ID: > When perceived runability is hung, try a ^\ ( control \) on console. >> This gets the JVM to dump the stacks of all the java threads. > > Good idea... A thread dump is below, it looks like only some system threads are in wait state which is probably normal. The "main" thread is stopped writing the first data out the serial port which should complete but its has stopped at: at gnu.io.RXTXPort.nativeDrain(Native Method) It show its state as runnable though. There is another thread, "SerialReader_22", that is waiting to read any data on the same port. I'll bring the app up under Netbeans debugger next. >> > I've also noticed some linux systems hanging with open/read/write and saw > kacpid storms. No CPU use going when it hangs, acts like a deadlock. THREAD DUMP AT HANG: Entering RXTXPort:SerialOutputStream:write(4) writeArray() Leaving RXTXPort:SerialOutputStream:write(4) RXTXPort:SerialOutputStream:flush() enter RXTXPort:SerialInputStream:read(8192 0 8192) called Full thread dump Java HotSpot(TM) Client VM (1.5.0_06-b05 mixed mode, sharing): "SerialReader_22" daemon prio=1 tid=0x087abf38 nid=0x3c8b runnable [0xb1a43000..0xb1a43f30] at gnu.io.RXTXPort.readArray(Native Method) at gnu.io.RXTXPort$SerialInputStream.read(RXTXPort.java:1454) - locked <0x88ca55b8> (a gnu.io.RXTXPort$SerialInputStream) at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:411) at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) - locked <0x88cab378> (a java.io.InputStreamReader) at java.io.InputStreamReader.read(InputStreamReader.java:167) at java.io.BufferedReader.fill(BufferedReader.java:136) at java.io.BufferedReader.readLine(BufferedReader.java:299) - locked <0x88cab378> (a java.io.InputStreamReader) at java.io.BufferedReader.readLine(BufferedReader.java:362) at qms.TSerialPort$SerialRead.run(TSerialPort.java:268) at java.lang.Thread.run(Thread.java:595) "Thread-1" prio=1 tid=0x08a43360 nid=0x3c8a runnable [0xb1ac4000..0xb1ac4db0] at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1641) "AWT-XAWT" daemon prio=1 tid=0x08acc848 nid=0x3c87 runnable [0xb1b45000..0xb1b45e30] at sun.awt.X11.XToolkit.waitForEvents(Native Method) at sun.awt.X11.XToolkit.run(XToolkit.java:463) at sun.awt.X11.XToolkit.run(XToolkit.java:438) at java.lang.Thread.run(Thread.java:595) "Java2D Disposer" daemon prio=1 tid=0x08ab9d30 nid=0x3c86 in Object.wait() [0xb1bc6000..0xb1bc70b0] at java.lang.Object.wait(Native Method) - waiting on <0x8917b110> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:116) - locked <0x8917b110> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:132) at sun.java2d.Disposer.run(Disposer.java:107) at java.lang.Thread.run(Thread.java:595) "Low Memory Detector" daemon prio=1 tid=0x087bea68 nid=0x3c84 runnable [0x00000000..0x00000000] "CompilerThread0" daemon prio=1 tid=0x087bd4c0 nid=0x3c83 waiting on condition [0x00000000..0xb23a7a18] "Signal Dispatcher" daemon prio=1 tid=0x087bc520 nid=0x3c82 runnable [0x00000000..0x00000000] "Finalizer" daemon prio=1 tid=0x087b5710 nid=0x3c81 in Object.wait() [0xb26a9000..0xb26a9f30] at java.lang.Object.wait(Native Method) - waiting on <0x8914a770> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:116) - locked <0x8914a770> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:132) at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159) "Reference Handler" daemon prio=1 tid=0x087b49c8 nid=0x3c80 in Object.wait() [0xb272a000..0xb272adb0] at java.lang.Object.wait(Native Method) - waiting on <0x8914a7f0> (a java.lang.ref.Reference$Lock) at java.lang.Object.wait(Object.java:474) at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116) - locked <0x8914a7f0> (a java.lang.ref.Reference$Lock) "main" prio=1 tid=0x08777b88 nid=0x3c7e runnable [0xbffa7000..0xbffa74f8] at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1248) at qms.TSerialPort.Transmit(TSerialPort.java:192) - locked <0x88c99a68> (a qms.TSerialPort) at qms.TIOBoard.GetIOBoardVersion(TIOBoard.java:168) at qms.TIOBoard.(TIOBoard.java:73) at qms.TQMS.(TQMS.java:47) at qms.MainForm.(MainForm.java:2076) at qms.MainForm.main(MainForm.java:2099) "VM Thread" prio=1 tid=0x087b1e20 nid=0x3c7f runnable "VM Periodic Task Thread" prio=1 tid=0x087bff50 nid=0x3c85 waiting on condition -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090403/20b7bca4/attachment-0001.html From Martin.Oberhuber at windriver.com Fri Apr 3 16:23:43 2009 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Sat, 4 Apr 2009 00:23:43 +0200 Subject: [Rxtx] Missing documentation In-Reply-To: <49D5973E.4050400@bbs.darktech.org> References: <49D43979.4050702@bbs.darktech.org> <49D5973E.4050400@bbs.darktech.org> Message-ID: <460801A4097E3D4CA04CC64EE648584809C8BD6F@ism-mail03.corp.ad.wrs.com> Hello Gili, The classes in the gnu.io namespace are designed to work exactly as their counterparts in the javax.comm namespace. Therefore, if you just take the javax.comm Javadocs that's what you want. Unfortunately I don't think we can just copy & paste the javax.comm Javadocs into RXTX due to license restrictions. I guess that's the main reason why RXTX is not (yet) Javadoc'd as extensively as it should be. Actually, writing Javadocs from scratch WITHOUT referencing the wording of the Sun Javadocs is not that easy. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of cowwoc > Sent: Freitag, 03. April 2009 06:58 > To: rxtx at qbang.org > Subject: [Rxtx] Missing documentation > > Hi, > > I noticed that RXTX 2.1 drops javax.comm support in favor > of gnu.io. > I have one major problem with this: the gui.io.* > documentation is very > poor. Many classes and methods have no Javadoc at all which > makes them > difficult to use. Please fix this for the final release. > > Thank you, > Gili > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Fri Apr 3 16:54:50 2009 From: netbeans at gatworks.com (U. George) Date: Fri, 03 Apr 2009 18:54:50 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: <49D546F8.20807@gatworks.com> Message-ID: <49D693BA.8060909@gatworks.com> I would have tried 2 or 3 "^\" . If things are stuck, then all will be at same 'java' instruction. If thread is moving, then one of the snapshots would be different. I *think* flushing/draining wont return until the kernel buffers to device have been accepted by device. Stuck/paused device? Bill Johnson wrote: > > > > > When perceived runability is hung, try a ^\ ( control \) on console. > This gets the JVM to dump the stacks of all the java threads. > > > Good idea... A thread dump is below, it looks like only some system > threads are in wait state which is prob From cowwoc at bbs.darktech.org Fri Apr 3 17:45:09 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Fri, 03 Apr 2009 19:45:09 -0400 Subject: [Rxtx] Missing documentation In-Reply-To: <460801A4097E3D4CA04CC64EE648584809C8BD6F@ism-mail03.corp.ad.wrs.com> References: <49D43979.4050702@bbs.darktech.org> <49D5973E.4050400@bbs.darktech.org> <460801A4097E3D4CA04CC64EE648584809C8BD6F@ism-mail03.corp.ad.wrs.com> Message-ID: <49D69F85.3030804@bbs.darktech.org> You could always send Sun a formal email and ask for permission to copy their Javadoc. I doubt they would give you problems. Gili Oberhuber, Martin wrote: > Hello Gili, > > The classes in the gnu.io namespace are designed to work exactly > as their counterparts in the javax.comm namespace. Therefore, > if you just take the javax.comm Javadocs that's what you want. > > Unfortunately I don't think we can just copy & paste the > javax.comm Javadocs into RXTX due to license restrictions. > > I guess that's the main reason why RXTX is not (yet) Javadoc'd > as extensively as it should be. Actually, writing Javadocs > from scratch WITHOUT referencing the wording of the Sun > Javadocs is not that easy. > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] >> On Behalf Of cowwoc >> Sent: Freitag, 03. April 2009 06:58 >> To: rxtx at qbang.org >> Subject: [Rxtx] Missing documentation >> >> Hi, >> >> I noticed that RXTX 2.1 drops javax.comm support in favor >> of gnu.io. >> I have one major problem with this: the gui.io.* >> documentation is very >> poor. Many classes and methods have no Javadoc at all which >> makes them >> difficult to use. Please fix this for the final release. >> >> Thank you, >> Gili >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> From cowwoc at bbs.darktech.org Wed Apr 1 22:05:13 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Thu, 02 Apr 2009 00:05:13 -0400 Subject: [Rxtx] Windows 64-bit support? Message-ID: <49D43979.4050702@bbs.darktech.org> Hi, I'd like to run RXTX under the Windows 64-bit JVM. Are there plans to release an official 64-bit version anytime soon? Gili From bill7007 at gmail.com Thu Apr 2 16:01:17 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Thu, 2 Apr 2009 18:01:17 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel Message-ID: Hi, I have an rxtx serial application that used to work reliably until I had to move it to newer hardware and kernel. Now, the application sometimes hangs near first port use. When it does hang, it can be released by starting a second copy of the application which is locked out of the ports but does release the first process. Upgraded from rxtx-2.1-7-r2 to rxtx-2.2pre2 but still hangs. Tried to rebuild on the target machine and ran into the 'UTS_RELEASE' undeclared problem so holding on that approach. Recompiled OK on a 2.6.9-42.0.3.ELsmp system. Debug messages were turned on using: "./configure --enable-DEBUG" and modified RXTXPort.java with: "debug = true;" "z = new Zystem(Zystem.PRINT_MODE);" Below is capture of the application with debugging enabled. It show the application hang point, and the second application's printout at the release point. (pre3 is the locally modified version of pre2) Any suggestions on how to pin this down further? Thanks, +BillJ $ java -version java version "1.5.0_06" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05) Java HotSpot(TM) Client VM (build 1.5.0_06-b05, mixed mode, sharing) $ uname -a Linux qms4 2.6.18-92.1.6.el5 #1 SMP Wed Jun 25 13:49:24 EDT 2008 i686 i686 i386 GNU/Linux ***CAPTURE: [qms at qms4 ~]$ ./qms/ScriptFiles/startup.sh Thu Apr 02 13:35:45 EDT 2009:Setting Log File to:/home/qms/qms/QMS.log Thu Apr 02 13:35:45 EDT 2009:TSettings.HandleIni:ReUsing Ini file:/home/qms/qms/qms.properties WARNING: RXTX Version mismatch Jar version = RXTX-2.2pre2 native lib Version = RXTX-2.2pre3 fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB2 fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB1 fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB0 fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile RXTXPort {} RXTX WARNING: This library was compiled to run with OS release 2.4.20 and you are currently running OS release 2.6.18-92.1.6.el5. In some cases this can be a problem. Try recompiling RXTX if you notice strange behavior. If you just compiled RXTX make sure /usr/include/linux is a symbolic link to the include files that came with the kernel source and not an older copy. press enter to continue RXTXPort:RXTXPort(/dev/ttyUSB2) called fhs_lock: creating lockfile: 10127 open: locking worked for /dev/ttyUSB2 open: fd returned is 8 RXTXPort:MontitorThread:MonitorThread() RXTXPort:MontitorThread:run() has_line_status_register_acess: Port does not support TIOCSERGETLSR init_threads: get eis init_threads: set eis init_threads: stop RXTXPort:RXTXPort(/dev/ttyUSB2) returns with fd = 8 RXTXPort:setSerialPortParams(38400 8 1 0) called RXTXPort:setSerialPortParams(38400 8 1 0) returning RXTXPort:getInputStream() called and returning Thu Apr 02 13:36:02 EDT 2009:TSerial[22]:Using Port:/dev/ttyUSB2 RXTXPort:getOutputStream() called and returning Thu Apr 02 13:36:02 EDT 2009:TSerial[22].Transmit:TN Entering RXTXPort:SerialOutputStream:write(4) writeArray() Leaving RXTXPort:SerialOutputStream:write(4) RXTXPort:SerialOutputStream:flush() enter RXTXPort:SerialOutputStream:flush() leave Thu Apr 02 13:36:02 EDT 2009:TSerial[22].Transmit:RV Entering RXTXPort:SerialOutputStream:write(4) writeArray() Leaving RXTXPort:SerialOutputStream:write(4) RXTXPort:SerialOutputStream:flush() enter RXTXPort:SerialInputStream:read(8192 0 8192) called ***FIRST PROCESS HANGS HERE ***THEN PROCEEDS AFTER SECOND PROCESS STARTS RXTXPort:SerialOutputStream:flush() leave Thu Apr 02 13:41:29 EDT 2009:TSerial[22].Transmit:IH9 Entering RXTXPort:SerialOutputStream:write(5) writeArray() Leaving RXTXPort:SerialOutputStream:write(5) RXTXPort:SerialOutputStream:flush() enter RXTXPort:SerialOutputStream:flush() leave Thu Apr 02 13:41:29 EDT 2009:TSerial[22].Transmit:IL11 ***END CAPTURE ***CAPTURE SECOND PROCESS FAILS OPEN [qms at qms4 ~]$ ./qms/ScriptFiles/startup.sh Thu Apr 02 13:41:27 EDT 2009:Setting Log File to:/home/qms/qms/QMS.log Thu Apr 02 13:41:27 EDT 2009:TSettings.HandleIni:ReUsing Ini file:/home/qms/qms/qms.properties WARNING: RXTX Version mismatch Jar version = RXTX-2.2pre2 native lib Version = RXTX-2.2pre3 fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB2: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB1: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB0: File exists fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB2: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB1: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB0: File exists fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile Thu Apr 02 13:41:30 EDT 2009:TIOBoard: java.io.IOException: java.io.IOException: TSerial[22]: Open Failed ***END CAPTURE -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090402/c66f8d70/attachment-0003.html From netbeans at gatworks.com Thu Apr 2 17:15:04 2009 From: netbeans at gatworks.com (U. George) Date: Thu, 02 Apr 2009 19:15:04 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: Message-ID: <49D546F8.20807@gatworks.com> > "z = new Zystem(Zystem.PRINT_MODE);" > Below is capture of the application with debugging enabled. It show > the application hang point, and the second application's printout at the > release point. (pre3 is the locally modified version of pre2) > Any suggestions on how to pin this down further? > Thanks, > +BillJ When perceived runability is hung, try a ^\ ( control \) on console. This gets the JVM to dump the stacks of all the java threads. If you know the thread that is stuck, then u can see what java statement its stuck at. From tjarvi at qbang.org Thu Apr 2 19:25:17 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 2 Apr 2009 19:25:17 -0600 (MDT) Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: <49D546F8.20807@gatworks.com> References: <49D546F8.20807@gatworks.com> Message-ID: On Thu, 2 Apr 2009, U. George wrote: >> "z = new Zystem(Zystem.PRINT_MODE);" >> Below is capture of the application with debugging enabled. It show >> the application hang point, and the second application's printout at the >> release point. (pre3 is the locally modified version of pre2) >> Any suggestions on how to pin this down further? >> Thanks, >> +BillJ > > When perceived runability is hung, try a ^\ ( control \) on console. > This gets the JVM to dump the stacks of all the java threads. > If you know the thread that is stuck, then u can see what java statement > its stuck at. I've also noticed some linux systems hanging with open/read/write and saw kacpid storms. I need to look at it more but did observe kacpid consuming a core and not returning to a normal state for a significant period of time. It was easy to observe from top sorted by CPU usage. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Apr 2 19:26:18 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 2 Apr 2009 19:26:18 -0600 (MDT) Subject: [Rxtx] Windows 64-bit support? In-Reply-To: <49D43979.4050702@bbs.darktech.org> References: <49D43979.4050702@bbs.darktech.org> Message-ID: On Thu, 2 Apr 2009, cowwoc wrote: > Hi, > > I'd like to run RXTX under the Windows 64-bit JVM. Are there plans > to release an official 64-bit version anytime soon? > It is in the prerelease and will be in the final release. I'm pushing it through as fast as I can in my free time. -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Thu Apr 2 22:57:34 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Fri, 03 Apr 2009 00:57:34 -0400 Subject: [Rxtx] Missing documentation In-Reply-To: References: <49D43979.4050702@bbs.darktech.org> Message-ID: <49D5973E.4050400@bbs.darktech.org> Hi, I noticed that RXTX 2.1 drops javax.comm support in favor of gnu.io. I have one major problem with this: the gui.io.* documentation is very poor. Many classes and methods have no Javadoc at all which makes them difficult to use. Please fix this for the final release. Thank you, Gili From alex.sas at freemail.hu Fri Apr 3 01:36:54 2009 From: alex.sas at freemail.hu (Sas Alex) Date: Fri, 3 Apr 2009 09:36:54 +0200 (CEST) Subject: [Rxtx] Serial port false reads Message-ID: Hi all, On Windows XP, using rxtx-2.1-7-r2 I have a program communicating on a serial line like the following (excerpt): { os.write(command); os.flush(); // Thread.sleep(period); // read response while(is.available() > 0) { is.read() } } If there is a sleep between the os.flush and the reading cycle the correct answer is received. Otherwise (sometimes) there are extra, erronous characters at the beginning of the answer, but the correct answer (according to the protocol) also arrives, afterwards. Is this a normal behaviour, one should wait before the read? If yes, is there a way to determine the minimum amount of time to wait for? Serial port params are: 9600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE. Thank you in advance, Alex ________________________________________________________ El?foglal?si akci? meghosszabb?tva! Korfui ?d?l?s m?r 56.910 Ft-t?l. http://www.budavartours.hu/gorogorszag/?utm_campaign=origo&utm_source=freemail_kimeno_090403&utm_medium=ct&utm_content=korfu_elofoglalasi_akcio#reg_Korfu -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090403/8f3650ea/attachment-0003.html From bill7007 at gmail.com Fri Apr 3 16:15:30 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Fri, 3 Apr 2009 18:15:30 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: <49D546F8.20807@gatworks.com> Message-ID: > When perceived runability is hung, try a ^\ ( control \) on console. >> This gets the JVM to dump the stacks of all the java threads. > > Good idea... A thread dump is below, it looks like only some system threads are in wait state which is probably normal. The "main" thread is stopped writing the first data out the serial port which should complete but its has stopped at: at gnu.io.RXTXPort.nativeDrain(Native Method) It show its state as runnable though. There is another thread, "SerialReader_22", that is waiting to read any data on the same port. I'll bring the app up under Netbeans debugger next. >> > I've also noticed some linux systems hanging with open/read/write and saw > kacpid storms. No CPU use going when it hangs, acts like a deadlock. THREAD DUMP AT HANG: Entering RXTXPort:SerialOutputStream:write(4) writeArray() Leaving RXTXPort:SerialOutputStream:write(4) RXTXPort:SerialOutputStream:flush() enter RXTXPort:SerialInputStream:read(8192 0 8192) called Full thread dump Java HotSpot(TM) Client VM (1.5.0_06-b05 mixed mode, sharing): "SerialReader_22" daemon prio=1 tid=0x087abf38 nid=0x3c8b runnable [0xb1a43000..0xb1a43f30] at gnu.io.RXTXPort.readArray(Native Method) at gnu.io.RXTXPort$SerialInputStream.read(RXTXPort.java:1454) - locked <0x88ca55b8> (a gnu.io.RXTXPort$SerialInputStream) at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:411) at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) - locked <0x88cab378> (a java.io.InputStreamReader) at java.io.InputStreamReader.read(InputStreamReader.java:167) at java.io.BufferedReader.fill(BufferedReader.java:136) at java.io.BufferedReader.readLine(BufferedReader.java:299) - locked <0x88cab378> (a java.io.InputStreamReader) at java.io.BufferedReader.readLine(BufferedReader.java:362) at qms.TSerialPort$SerialRead.run(TSerialPort.java:268) at java.lang.Thread.run(Thread.java:595) "Thread-1" prio=1 tid=0x08a43360 nid=0x3c8a runnable [0xb1ac4000..0xb1ac4db0] at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1641) "AWT-XAWT" daemon prio=1 tid=0x08acc848 nid=0x3c87 runnable [0xb1b45000..0xb1b45e30] at sun.awt.X11.XToolkit.waitForEvents(Native Method) at sun.awt.X11.XToolkit.run(XToolkit.java:463) at sun.awt.X11.XToolkit.run(XToolkit.java:438) at java.lang.Thread.run(Thread.java:595) "Java2D Disposer" daemon prio=1 tid=0x08ab9d30 nid=0x3c86 in Object.wait() [0xb1bc6000..0xb1bc70b0] at java.lang.Object.wait(Native Method) - waiting on <0x8917b110> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:116) - locked <0x8917b110> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:132) at sun.java2d.Disposer.run(Disposer.java:107) at java.lang.Thread.run(Thread.java:595) "Low Memory Detector" daemon prio=1 tid=0x087bea68 nid=0x3c84 runnable [0x00000000..0x00000000] "CompilerThread0" daemon prio=1 tid=0x087bd4c0 nid=0x3c83 waiting on condition [0x00000000..0xb23a7a18] "Signal Dispatcher" daemon prio=1 tid=0x087bc520 nid=0x3c82 runnable [0x00000000..0x00000000] "Finalizer" daemon prio=1 tid=0x087b5710 nid=0x3c81 in Object.wait() [0xb26a9000..0xb26a9f30] at java.lang.Object.wait(Native Method) - waiting on <0x8914a770> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:116) - locked <0x8914a770> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:132) at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159) "Reference Handler" daemon prio=1 tid=0x087b49c8 nid=0x3c80 in Object.wait() [0xb272a000..0xb272adb0] at java.lang.Object.wait(Native Method) - waiting on <0x8914a7f0> (a java.lang.ref.Reference$Lock) at java.lang.Object.wait(Object.java:474) at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116) - locked <0x8914a7f0> (a java.lang.ref.Reference$Lock) "main" prio=1 tid=0x08777b88 nid=0x3c7e runnable [0xbffa7000..0xbffa74f8] at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1248) at qms.TSerialPort.Transmit(TSerialPort.java:192) - locked <0x88c99a68> (a qms.TSerialPort) at qms.TIOBoard.GetIOBoardVersion(TIOBoard.java:168) at qms.TIOBoard.(TIOBoard.java:73) at qms.TQMS.(TQMS.java:47) at qms.MainForm.(MainForm.java:2076) at qms.MainForm.main(MainForm.java:2099) "VM Thread" prio=1 tid=0x087b1e20 nid=0x3c7f runnable "VM Periodic Task Thread" prio=1 tid=0x087bff50 nid=0x3c85 waiting on condition -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090403/20b7bca4/attachment-0002.html From Martin.Oberhuber at windriver.com Fri Apr 3 16:23:43 2009 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Sat, 4 Apr 2009 00:23:43 +0200 Subject: [Rxtx] Missing documentation In-Reply-To: <49D5973E.4050400@bbs.darktech.org> References: <49D43979.4050702@bbs.darktech.org> <49D5973E.4050400@bbs.darktech.org> Message-ID: <460801A4097E3D4CA04CC64EE648584809C8BD6F@ism-mail03.corp.ad.wrs.com> Hello Gili, The classes in the gnu.io namespace are designed to work exactly as their counterparts in the javax.comm namespace. Therefore, if you just take the javax.comm Javadocs that's what you want. Unfortunately I don't think we can just copy & paste the javax.comm Javadocs into RXTX due to license restrictions. I guess that's the main reason why RXTX is not (yet) Javadoc'd as extensively as it should be. Actually, writing Javadocs from scratch WITHOUT referencing the wording of the Sun Javadocs is not that easy. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of cowwoc > Sent: Freitag, 03. April 2009 06:58 > To: rxtx at qbang.org > Subject: [Rxtx] Missing documentation > > Hi, > > I noticed that RXTX 2.1 drops javax.comm support in favor > of gnu.io. > I have one major problem with this: the gui.io.* > documentation is very > poor. Many classes and methods have no Javadoc at all which > makes them > difficult to use. Please fix this for the final release. > > Thank you, > Gili > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Fri Apr 3 16:54:50 2009 From: netbeans at gatworks.com (U. George) Date: Fri, 03 Apr 2009 18:54:50 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: <49D546F8.20807@gatworks.com> Message-ID: <49D693BA.8060909@gatworks.com> I would have tried 2 or 3 "^\" . If things are stuck, then all will be at same 'java' instruction. If thread is moving, then one of the snapshots would be different. I *think* flushing/draining wont return until the kernel buffers to device have been accepted by device. Stuck/paused device? Bill Johnson wrote: > > > > > When perceived runability is hung, try a ^\ ( control \) on console. > This gets the JVM to dump the stacks of all the java threads. > > > Good idea... A thread dump is below, it looks like only some system > threads are in wait state which is prob From cowwoc at bbs.darktech.org Fri Apr 3 17:45:09 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Fri, 03 Apr 2009 19:45:09 -0400 Subject: [Rxtx] Missing documentation In-Reply-To: <460801A4097E3D4CA04CC64EE648584809C8BD6F@ism-mail03.corp.ad.wrs.com> References: <49D43979.4050702@bbs.darktech.org> <49D5973E.4050400@bbs.darktech.org> <460801A4097E3D4CA04CC64EE648584809C8BD6F@ism-mail03.corp.ad.wrs.com> Message-ID: <49D69F85.3030804@bbs.darktech.org> You could always send Sun a formal email and ask for permission to copy their Javadoc. I doubt they would give you problems. Gili Oberhuber, Martin wrote: > Hello Gili, > > The classes in the gnu.io namespace are designed to work exactly > as their counterparts in the javax.comm namespace. Therefore, > if you just take the javax.comm Javadocs that's what you want. > > Unfortunately I don't think we can just copy & paste the > javax.comm Javadocs into RXTX due to license restrictions. > > I guess that's the main reason why RXTX is not (yet) Javadoc'd > as extensively as it should be. Actually, writing Javadocs > from scratch WITHOUT referencing the wording of the Sun > Javadocs is not that easy. > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] >> On Behalf Of cowwoc >> Sent: Freitag, 03. April 2009 06:58 >> To: rxtx at qbang.org >> Subject: [Rxtx] Missing documentation >> >> Hi, >> >> I noticed that RXTX 2.1 drops javax.comm support in favor >> of gnu.io. >> I have one major problem with this: the gui.io.* >> documentation is very >> poor. Many classes and methods have no Javadoc at all which >> makes them >> difficult to use. Please fix this for the final release. >> >> Thank you, >> Gili >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> From cowwoc at bbs.darktech.org Sat Apr 4 15:13:38 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sat, 04 Apr 2009 17:13:38 -0400 Subject: [Rxtx] Java5 support Message-ID: <49D7CD82.1040904@bbs.darktech.org> Now that you dropped javax.comm support, how about improving the API by replacing Enumation by Iterator, int by enum, and using Generics? It would improve the usability of the API. Gili From cowwoc at bbs.darktech.org Sat Apr 4 16:12:13 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sat, 04 Apr 2009 18:12:13 -0400 Subject: [Rxtx] RXTX Version mismatch in 2.2pre2 Message-ID: <49D7DB3D.5040008@bbs.darktech.org> When using RXTX-2.2pre2 I always get the following message: WARNING: RXTX Version mismatch Jar version = RXTX-2.2pre1 native lib Version = RXTX-2.2pre2 I have double checked that I am using the correct Jar file. Is this a known bug in pre2? Gili From tjarvi at qbang.org Sat Apr 4 16:48:53 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Apr 2009 16:48:53 -0600 (MDT) Subject: [Rxtx] RXTX Version mismatch in 2.2pre2 In-Reply-To: <49D7DB3D.5040008@bbs.darktech.org> References: <49D7DB3D.5040008@bbs.darktech.org> Message-ID: > When using RXTX-2.2pre2 I always get the following message: > > WARNING: RXTX Version mismatch > Jar version = RXTX-2.2pre1 > native lib Version = RXTX-2.2pre2 > Yep. You should still be able to test it. -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Sat Apr 4 16:50:43 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sat, 04 Apr 2009 18:50:43 -0400 Subject: [Rxtx] RXTX Version mismatch in 2.2pre2 In-Reply-To: References: <49D7DB3D.5040008@bbs.darktech.org> Message-ID: <49D7E443.9070404@bbs.darktech.org> In other words this is a known bug that will be fixed in the final version? Gili Trent Jarvi wrote: > > >> When using RXTX-2.2pre2 I always get the following message: >> >> WARNING: RXTX Version mismatch >> Jar version = RXTX-2.2pre1 >> native lib Version = RXTX-2.2pre2 >> > > Yep. > > You should still be able to test it. > > -- > Trent Jarvi > tjarvi at qbang.org From cowwoc at bbs.darktech.org Sat Apr 4 16:57:34 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sat, 04 Apr 2009 18:57:34 -0400 Subject: [Rxtx] IOException: Underlying input stream returned zero bytes Message-ID: <49D7E5DE.2050405@bbs.darktech.org> Hi, There seems to be a bug in RXTX 2.2pre2's handling of InputStream timeouts. If you open a serial port without ever invoking enableReceiveTimeout() then invoking InputStream.read() will always return 0 bytes right away. If you wrap the InputStream and invoke BufferedReader.readline() you will get the following exception: java.io.IOException: Underlying input stream returned zero bytes at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:268) [na:1.6.0_14-ea] at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:306) [na:1.6.0_14-ea] at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:158) [na:1.6.0_14-ea] at java.io.InputStreamReader.read(InputStreamReader.java:167) [na:1.6.0_14-ea] at java.io.BufferedReader.fill(BufferedReader.java:136) [na:1.6.0_14-ea] at java.io.BufferedReader.readLine(BufferedReader.java:299) [na:1.6.0_14-ea] at java.io.BufferedReader.readLine(BufferedReader.java:362) [na:1.6.0_14-ea] [snip] If you enable a timeout, the exception will only occur after the timeout expires. In short, it looks like RXTX is using a default timeout of zero (I am expecting it to block forever). It looks like other people have run into this as well: http://forums.sun.com/thread.jspa?threadID=5165346&start=10&tstart=0 Please confirm whether this is a known bug. Thank you, Gili From tjarvi at qbang.org Sat Apr 4 17:27:19 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Apr 2009 17:27:19 -0600 (MDT) Subject: [Rxtx] IOException: Underlying input stream returned zero bytes In-Reply-To: <49D7E5DE.2050405@bbs.darktech.org> References: <49D7E5DE.2050405@bbs.darktech.org> Message-ID: On Sat, 4 Apr 2009, cowwoc wrote: > Hi, > > There seems to be a bug in RXTX 2.2pre2's handling of InputStream > timeouts. If you open a serial port without ever invoking > enableReceiveTimeout() then invoking InputStream.read() will always > return 0 bytes right away. If you wrap the InputStream and invoke > BufferedReader.readline() you will get the following exception: > > java.io.IOException: Underlying input stream returned zero bytes > at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:268) > [na:1.6.0_14-ea] > at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:306) > [na:1.6.0_14-ea] > at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:158) > [na:1.6.0_14-ea] > at java.io.InputStreamReader.read(InputStreamReader.java:167) > [na:1.6.0_14-ea] > at java.io.BufferedReader.fill(BufferedReader.java:136) > [na:1.6.0_14-ea] > at java.io.BufferedReader.readLine(BufferedReader.java:299) > [na:1.6.0_14-ea] > at java.io.BufferedReader.readLine(BufferedReader.java:362) > [na:1.6.0_14-ea] > [snip] > > If you enable a timeout, the exception will only occur after the > timeout expires. In short, it looks like RXTX is using a default timeout > of zero (I am expecting it to block forever). It looks like other people > have run into this as well: > http://forums.sun.com/thread.jspa?threadID=5165346&start=10&tstart=0 > > Please confirm whether this is a known bug. > Hi Gili I've known about it but was not sure if it was a bug or not. It looks like we can treat it as a bug if nio is throwing an exception. Timeout and Thresholds are well documented in javax.comm but I didn't recall seeing defaults. For that reason, I've encouraged people to set the threshold and timeout to what they expect. Another note about InputStream.read(void): I noticed that I don't use that function at all while looking at code coverage results. Keep your eye out for additional issues. -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Sat Apr 4 19:03:29 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sat, 04 Apr 2009 21:03:29 -0400 Subject: [Rxtx] IOException: Underlying input stream returned zero bytes In-Reply-To: References: <49D7E5DE.2050405@bbs.darktech.org> Message-ID: <49D80361.7020801@bbs.darktech.org> Trent Jarvi wrote: > For that reason, I've encouraged people to set the threshold and timeout > to what they expect. It doesn't help. There doesn't seem to be a way to disable the timeout, even if you invoke disableReceiveTimeout() explicitly. Let me know when you put in a fix and I will test it. Thanks, Gili From cowwoc at bbs.darktech.org Sat Apr 4 23:27:25 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 01:27:25 -0400 Subject: [Rxtx] Crash in termios.c:892 Message-ID: <49D8413D.7040105@bbs.darktech.org> I can reproduce a crash in RXTX 2.2 pre2 100% of the time using my application code, but I can't seem to bring it down to a minimal testcase. Here is what I see: - thread begins running - open com1 - close com1 - open com5 - leave com5 open - thread shuts down - repeat the same process in a new thread - crash occurs when trying to open com1. Crash disappears if I close() com5 in the previous thread. The output window contains the following: # # A fatal error has been detected by the Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x05475cf6, pid=6064, tid=5436 # # JRE version: 6.0_14-b04 # Java VM: Java HotSpot(TM) Client VM (14.0-b13 mixed mode, sharing windows-x86 ) # Problematic frame: # C [rxtxSerial.dll+0x5cf6] # # An error report file with more information is saved as: # C:\Users\Gili\Documents\foobar\source\hs_err_pid6064.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp Error 0x5 at ..\src\termios.c(892): Access is denied. # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # Please let me know if the crash dump is enough to track down this bug. Thank you, Gili -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: hs_err_pid6064.log Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20090405/7133a1ce/attachment-0001.ksh From cowwoc at bbs.darktech.org Sun Apr 5 00:24:19 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 02:24:19 -0400 Subject: [Rxtx] SerialPort.getName() is wrong Message-ID: <49D84E93.7050606@bbs.darktech.org> Sorry for all these emails but I keep on running into more issues. Here is what I noticed: - CommPortIdentifier.getPortIdentifier("COM5") returns a CommPortIdentifier where getName() == "COM5" - If, however, you invoke CommPortIdentifier.open() you get back a SerialPort where SerialPort.getName() is "//./COM5" I am expecting the name to remain consistent. "//./COM5" looks like an implementation detail and (as far as I can tell) it can't be used as an argument for any API method so it is somewhat useless. If getName() were to return "COM5" I could at least use it to get back the original CommPortIdentifier or compare against "known names" such as "COMx" or "LPTx". What do you think? Gili From cowwoc at bbs.darktech.org Wed Apr 1 22:05:13 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Thu, 02 Apr 2009 00:05:13 -0400 Subject: [Rxtx] Windows 64-bit support? Message-ID: <49D43979.4050702@bbs.darktech.org> Hi, I'd like to run RXTX under the Windows 64-bit JVM. Are there plans to release an official 64-bit version anytime soon? Gili From bill7007 at gmail.com Thu Apr 2 16:01:17 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Thu, 2 Apr 2009 18:01:17 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel Message-ID: Hi, I have an rxtx serial application that used to work reliably until I had to move it to newer hardware and kernel. Now, the application sometimes hangs near first port use. When it does hang, it can be released by starting a second copy of the application which is locked out of the ports but does release the first process. Upgraded from rxtx-2.1-7-r2 to rxtx-2.2pre2 but still hangs. Tried to rebuild on the target machine and ran into the 'UTS_RELEASE' undeclared problem so holding on that approach. Recompiled OK on a 2.6.9-42.0.3.ELsmp system. Debug messages were turned on using: "./configure --enable-DEBUG" and modified RXTXPort.java with: "debug = true;" "z = new Zystem(Zystem.PRINT_MODE);" Below is capture of the application with debugging enabled. It show the application hang point, and the second application's printout at the release point. (pre3 is the locally modified version of pre2) Any suggestions on how to pin this down further? Thanks, +BillJ $ java -version java version "1.5.0_06" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05) Java HotSpot(TM) Client VM (build 1.5.0_06-b05, mixed mode, sharing) $ uname -a Linux qms4 2.6.18-92.1.6.el5 #1 SMP Wed Jun 25 13:49:24 EDT 2008 i686 i686 i386 GNU/Linux ***CAPTURE: [qms at qms4 ~]$ ./qms/ScriptFiles/startup.sh Thu Apr 02 13:35:45 EDT 2009:Setting Log File to:/home/qms/qms/QMS.log Thu Apr 02 13:35:45 EDT 2009:TSettings.HandleIni:ReUsing Ini file:/home/qms/qms/qms.properties WARNING: RXTX Version mismatch Jar version = RXTX-2.2pre2 native lib Version = RXTX-2.2pre3 fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB2 fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB1 fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB0 fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile RXTXPort {} RXTX WARNING: This library was compiled to run with OS release 2.4.20 and you are currently running OS release 2.6.18-92.1.6.el5. In some cases this can be a problem. Try recompiling RXTX if you notice strange behavior. If you just compiled RXTX make sure /usr/include/linux is a symbolic link to the include files that came with the kernel source and not an older copy. press enter to continue RXTXPort:RXTXPort(/dev/ttyUSB2) called fhs_lock: creating lockfile: 10127 open: locking worked for /dev/ttyUSB2 open: fd returned is 8 RXTXPort:MontitorThread:MonitorThread() RXTXPort:MontitorThread:run() has_line_status_register_acess: Port does not support TIOCSERGETLSR init_threads: get eis init_threads: set eis init_threads: stop RXTXPort:RXTXPort(/dev/ttyUSB2) returns with fd = 8 RXTXPort:setSerialPortParams(38400 8 1 0) called RXTXPort:setSerialPortParams(38400 8 1 0) returning RXTXPort:getInputStream() called and returning Thu Apr 02 13:36:02 EDT 2009:TSerial[22]:Using Port:/dev/ttyUSB2 RXTXPort:getOutputStream() called and returning Thu Apr 02 13:36:02 EDT 2009:TSerial[22].Transmit:TN Entering RXTXPort:SerialOutputStream:write(4) writeArray() Leaving RXTXPort:SerialOutputStream:write(4) RXTXPort:SerialOutputStream:flush() enter RXTXPort:SerialOutputStream:flush() leave Thu Apr 02 13:36:02 EDT 2009:TSerial[22].Transmit:RV Entering RXTXPort:SerialOutputStream:write(4) writeArray() Leaving RXTXPort:SerialOutputStream:write(4) RXTXPort:SerialOutputStream:flush() enter RXTXPort:SerialInputStream:read(8192 0 8192) called ***FIRST PROCESS HANGS HERE ***THEN PROCEEDS AFTER SECOND PROCESS STARTS RXTXPort:SerialOutputStream:flush() leave Thu Apr 02 13:41:29 EDT 2009:TSerial[22].Transmit:IH9 Entering RXTXPort:SerialOutputStream:write(5) writeArray() Leaving RXTXPort:SerialOutputStream:write(5) RXTXPort:SerialOutputStream:flush() enter RXTXPort:SerialOutputStream:flush() leave Thu Apr 02 13:41:29 EDT 2009:TSerial[22].Transmit:IL11 ***END CAPTURE ***CAPTURE SECOND PROCESS FAILS OPEN [qms at qms4 ~]$ ./qms/ScriptFiles/startup.sh Thu Apr 02 13:41:27 EDT 2009:Setting Log File to:/home/qms/qms/QMS.log Thu Apr 02 13:41:27 EDT 2009:TSettings.HandleIni:ReUsing Ini file:/home/qms/qms/qms.properties WARNING: RXTX Version mismatch Jar version = RXTX-2.2pre2 native lib Version = RXTX-2.2pre3 fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB2: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB1: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB0: File exists fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB2: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB1: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB0: File exists fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile Thu Apr 02 13:41:30 EDT 2009:TIOBoard: java.io.IOException: java.io.IOException: TSerial[22]: Open Failed ***END CAPTURE -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090402/c66f8d70/attachment-0004.html From netbeans at gatworks.com Thu Apr 2 17:15:04 2009 From: netbeans at gatworks.com (U. George) Date: Thu, 02 Apr 2009 19:15:04 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: Message-ID: <49D546F8.20807@gatworks.com> > "z = new Zystem(Zystem.PRINT_MODE);" > Below is capture of the application with debugging enabled. It show > the application hang point, and the second application's printout at the > release point. (pre3 is the locally modified version of pre2) > Any suggestions on how to pin this down further? > Thanks, > +BillJ When perceived runability is hung, try a ^\ ( control \) on console. This gets the JVM to dump the stacks of all the java threads. If you know the thread that is stuck, then u can see what java statement its stuck at. From tjarvi at qbang.org Thu Apr 2 19:25:17 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 2 Apr 2009 19:25:17 -0600 (MDT) Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: <49D546F8.20807@gatworks.com> References: <49D546F8.20807@gatworks.com> Message-ID: On Thu, 2 Apr 2009, U. George wrote: >> "z = new Zystem(Zystem.PRINT_MODE);" >> Below is capture of the application with debugging enabled. It show >> the application hang point, and the second application's printout at the >> release point. (pre3 is the locally modified version of pre2) >> Any suggestions on how to pin this down further? >> Thanks, >> +BillJ > > When perceived runability is hung, try a ^\ ( control \) on console. > This gets the JVM to dump the stacks of all the java threads. > If you know the thread that is stuck, then u can see what java statement > its stuck at. I've also noticed some linux systems hanging with open/read/write and saw kacpid storms. I need to look at it more but did observe kacpid consuming a core and not returning to a normal state for a significant period of time. It was easy to observe from top sorted by CPU usage. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Apr 2 19:26:18 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 2 Apr 2009 19:26:18 -0600 (MDT) Subject: [Rxtx] Windows 64-bit support? In-Reply-To: <49D43979.4050702@bbs.darktech.org> References: <49D43979.4050702@bbs.darktech.org> Message-ID: On Thu, 2 Apr 2009, cowwoc wrote: > Hi, > > I'd like to run RXTX under the Windows 64-bit JVM. Are there plans > to release an official 64-bit version anytime soon? > It is in the prerelease and will be in the final release. I'm pushing it through as fast as I can in my free time. -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Thu Apr 2 22:57:34 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Fri, 03 Apr 2009 00:57:34 -0400 Subject: [Rxtx] Missing documentation In-Reply-To: References: <49D43979.4050702@bbs.darktech.org> Message-ID: <49D5973E.4050400@bbs.darktech.org> Hi, I noticed that RXTX 2.1 drops javax.comm support in favor of gnu.io. I have one major problem with this: the gui.io.* documentation is very poor. Many classes and methods have no Javadoc at all which makes them difficult to use. Please fix this for the final release. Thank you, Gili From alex.sas at freemail.hu Fri Apr 3 01:36:54 2009 From: alex.sas at freemail.hu (Sas Alex) Date: Fri, 3 Apr 2009 09:36:54 +0200 (CEST) Subject: [Rxtx] Serial port false reads Message-ID: Hi all, On Windows XP, using rxtx-2.1-7-r2 I have a program communicating on a serial line like the following (excerpt): { os.write(command); os.flush(); // Thread.sleep(period); // read response while(is.available() > 0) { is.read() } } If there is a sleep between the os.flush and the reading cycle the correct answer is received. Otherwise (sometimes) there are extra, erronous characters at the beginning of the answer, but the correct answer (according to the protocol) also arrives, afterwards. Is this a normal behaviour, one should wait before the read? If yes, is there a way to determine the minimum amount of time to wait for? Serial port params are: 9600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE. Thank you in advance, Alex ________________________________________________________ El?foglal?si akci? meghosszabb?tva! Korfui ?d?l?s m?r 56.910 Ft-t?l. http://www.budavartours.hu/gorogorszag/?utm_campaign=origo&utm_source=freemail_kimeno_090403&utm_medium=ct&utm_content=korfu_elofoglalasi_akcio#reg_Korfu -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090403/8f3650ea/attachment-0004.html From bill7007 at gmail.com Fri Apr 3 16:15:30 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Fri, 3 Apr 2009 18:15:30 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: <49D546F8.20807@gatworks.com> Message-ID: > When perceived runability is hung, try a ^\ ( control \) on console. >> This gets the JVM to dump the stacks of all the java threads. > > Good idea... A thread dump is below, it looks like only some system threads are in wait state which is probably normal. The "main" thread is stopped writing the first data out the serial port which should complete but its has stopped at: at gnu.io.RXTXPort.nativeDrain(Native Method) It show its state as runnable though. There is another thread, "SerialReader_22", that is waiting to read any data on the same port. I'll bring the app up under Netbeans debugger next. >> > I've also noticed some linux systems hanging with open/read/write and saw > kacpid storms. No CPU use going when it hangs, acts like a deadlock. THREAD DUMP AT HANG: Entering RXTXPort:SerialOutputStream:write(4) writeArray() Leaving RXTXPort:SerialOutputStream:write(4) RXTXPort:SerialOutputStream:flush() enter RXTXPort:SerialInputStream:read(8192 0 8192) called Full thread dump Java HotSpot(TM) Client VM (1.5.0_06-b05 mixed mode, sharing): "SerialReader_22" daemon prio=1 tid=0x087abf38 nid=0x3c8b runnable [0xb1a43000..0xb1a43f30] at gnu.io.RXTXPort.readArray(Native Method) at gnu.io.RXTXPort$SerialInputStream.read(RXTXPort.java:1454) - locked <0x88ca55b8> (a gnu.io.RXTXPort$SerialInputStream) at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:411) at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) - locked <0x88cab378> (a java.io.InputStreamReader) at java.io.InputStreamReader.read(InputStreamReader.java:167) at java.io.BufferedReader.fill(BufferedReader.java:136) at java.io.BufferedReader.readLine(BufferedReader.java:299) - locked <0x88cab378> (a java.io.InputStreamReader) at java.io.BufferedReader.readLine(BufferedReader.java:362) at qms.TSerialPort$SerialRead.run(TSerialPort.java:268) at java.lang.Thread.run(Thread.java:595) "Thread-1" prio=1 tid=0x08a43360 nid=0x3c8a runnable [0xb1ac4000..0xb1ac4db0] at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1641) "AWT-XAWT" daemon prio=1 tid=0x08acc848 nid=0x3c87 runnable [0xb1b45000..0xb1b45e30] at sun.awt.X11.XToolkit.waitForEvents(Native Method) at sun.awt.X11.XToolkit.run(XToolkit.java:463) at sun.awt.X11.XToolkit.run(XToolkit.java:438) at java.lang.Thread.run(Thread.java:595) "Java2D Disposer" daemon prio=1 tid=0x08ab9d30 nid=0x3c86 in Object.wait() [0xb1bc6000..0xb1bc70b0] at java.lang.Object.wait(Native Method) - waiting on <0x8917b110> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:116) - locked <0x8917b110> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:132) at sun.java2d.Disposer.run(Disposer.java:107) at java.lang.Thread.run(Thread.java:595) "Low Memory Detector" daemon prio=1 tid=0x087bea68 nid=0x3c84 runnable [0x00000000..0x00000000] "CompilerThread0" daemon prio=1 tid=0x087bd4c0 nid=0x3c83 waiting on condition [0x00000000..0xb23a7a18] "Signal Dispatcher" daemon prio=1 tid=0x087bc520 nid=0x3c82 runnable [0x00000000..0x00000000] "Finalizer" daemon prio=1 tid=0x087b5710 nid=0x3c81 in Object.wait() [0xb26a9000..0xb26a9f30] at java.lang.Object.wait(Native Method) - waiting on <0x8914a770> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:116) - locked <0x8914a770> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:132) at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159) "Reference Handler" daemon prio=1 tid=0x087b49c8 nid=0x3c80 in Object.wait() [0xb272a000..0xb272adb0] at java.lang.Object.wait(Native Method) - waiting on <0x8914a7f0> (a java.lang.ref.Reference$Lock) at java.lang.Object.wait(Object.java:474) at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116) - locked <0x8914a7f0> (a java.lang.ref.Reference$Lock) "main" prio=1 tid=0x08777b88 nid=0x3c7e runnable [0xbffa7000..0xbffa74f8] at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1248) at qms.TSerialPort.Transmit(TSerialPort.java:192) - locked <0x88c99a68> (a qms.TSerialPort) at qms.TIOBoard.GetIOBoardVersion(TIOBoard.java:168) at qms.TIOBoard.(TIOBoard.java:73) at qms.TQMS.(TQMS.java:47) at qms.MainForm.(MainForm.java:2076) at qms.MainForm.main(MainForm.java:2099) "VM Thread" prio=1 tid=0x087b1e20 nid=0x3c7f runnable "VM Periodic Task Thread" prio=1 tid=0x087bff50 nid=0x3c85 waiting on condition -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090403/20b7bca4/attachment-0003.html From Martin.Oberhuber at windriver.com Fri Apr 3 16:23:43 2009 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Sat, 4 Apr 2009 00:23:43 +0200 Subject: [Rxtx] Missing documentation In-Reply-To: <49D5973E.4050400@bbs.darktech.org> References: <49D43979.4050702@bbs.darktech.org> <49D5973E.4050400@bbs.darktech.org> Message-ID: <460801A4097E3D4CA04CC64EE648584809C8BD6F@ism-mail03.corp.ad.wrs.com> Hello Gili, The classes in the gnu.io namespace are designed to work exactly as their counterparts in the javax.comm namespace. Therefore, if you just take the javax.comm Javadocs that's what you want. Unfortunately I don't think we can just copy & paste the javax.comm Javadocs into RXTX due to license restrictions. I guess that's the main reason why RXTX is not (yet) Javadoc'd as extensively as it should be. Actually, writing Javadocs from scratch WITHOUT referencing the wording of the Sun Javadocs is not that easy. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of cowwoc > Sent: Freitag, 03. April 2009 06:58 > To: rxtx at qbang.org > Subject: [Rxtx] Missing documentation > > Hi, > > I noticed that RXTX 2.1 drops javax.comm support in favor > of gnu.io. > I have one major problem with this: the gui.io.* > documentation is very > poor. Many classes and methods have no Javadoc at all which > makes them > difficult to use. Please fix this for the final release. > > Thank you, > Gili > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Fri Apr 3 16:54:50 2009 From: netbeans at gatworks.com (U. George) Date: Fri, 03 Apr 2009 18:54:50 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: <49D546F8.20807@gatworks.com> Message-ID: <49D693BA.8060909@gatworks.com> I would have tried 2 or 3 "^\" . If things are stuck, then all will be at same 'java' instruction. If thread is moving, then one of the snapshots would be different. I *think* flushing/draining wont return until the kernel buffers to device have been accepted by device. Stuck/paused device? Bill Johnson wrote: > > > > > When perceived runability is hung, try a ^\ ( control \) on console. > This gets the JVM to dump the stacks of all the java threads. > > > Good idea... A thread dump is below, it looks like only some system > threads are in wait state which is prob From cowwoc at bbs.darktech.org Fri Apr 3 17:45:09 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Fri, 03 Apr 2009 19:45:09 -0400 Subject: [Rxtx] Missing documentation In-Reply-To: <460801A4097E3D4CA04CC64EE648584809C8BD6F@ism-mail03.corp.ad.wrs.com> References: <49D43979.4050702@bbs.darktech.org> <49D5973E.4050400@bbs.darktech.org> <460801A4097E3D4CA04CC64EE648584809C8BD6F@ism-mail03.corp.ad.wrs.com> Message-ID: <49D69F85.3030804@bbs.darktech.org> You could always send Sun a formal email and ask for permission to copy their Javadoc. I doubt they would give you problems. Gili Oberhuber, Martin wrote: > Hello Gili, > > The classes in the gnu.io namespace are designed to work exactly > as their counterparts in the javax.comm namespace. Therefore, > if you just take the javax.comm Javadocs that's what you want. > > Unfortunately I don't think we can just copy & paste the > javax.comm Javadocs into RXTX due to license restrictions. > > I guess that's the main reason why RXTX is not (yet) Javadoc'd > as extensively as it should be. Actually, writing Javadocs > from scratch WITHOUT referencing the wording of the Sun > Javadocs is not that easy. > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] >> On Behalf Of cowwoc >> Sent: Freitag, 03. April 2009 06:58 >> To: rxtx at qbang.org >> Subject: [Rxtx] Missing documentation >> >> Hi, >> >> I noticed that RXTX 2.1 drops javax.comm support in favor >> of gnu.io. >> I have one major problem with this: the gui.io.* >> documentation is very >> poor. Many classes and methods have no Javadoc at all which >> makes them >> difficult to use. Please fix this for the final release. >> >> Thank you, >> Gili >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> From cowwoc at bbs.darktech.org Sat Apr 4 15:13:38 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sat, 04 Apr 2009 17:13:38 -0400 Subject: [Rxtx] Java5 support Message-ID: <49D7CD82.1040904@bbs.darktech.org> Now that you dropped javax.comm support, how about improving the API by replacing Enumation by Iterator, int by enum, and using Generics? It would improve the usability of the API. Gili From cowwoc at bbs.darktech.org Sat Apr 4 16:12:13 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sat, 04 Apr 2009 18:12:13 -0400 Subject: [Rxtx] RXTX Version mismatch in 2.2pre2 Message-ID: <49D7DB3D.5040008@bbs.darktech.org> When using RXTX-2.2pre2 I always get the following message: WARNING: RXTX Version mismatch Jar version = RXTX-2.2pre1 native lib Version = RXTX-2.2pre2 I have double checked that I am using the correct Jar file. Is this a known bug in pre2? Gili From tjarvi at qbang.org Sat Apr 4 16:48:53 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Apr 2009 16:48:53 -0600 (MDT) Subject: [Rxtx] RXTX Version mismatch in 2.2pre2 In-Reply-To: <49D7DB3D.5040008@bbs.darktech.org> References: <49D7DB3D.5040008@bbs.darktech.org> Message-ID: > When using RXTX-2.2pre2 I always get the following message: > > WARNING: RXTX Version mismatch > Jar version = RXTX-2.2pre1 > native lib Version = RXTX-2.2pre2 > Yep. You should still be able to test it. -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Sat Apr 4 16:50:43 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sat, 04 Apr 2009 18:50:43 -0400 Subject: [Rxtx] RXTX Version mismatch in 2.2pre2 In-Reply-To: References: <49D7DB3D.5040008@bbs.darktech.org> Message-ID: <49D7E443.9070404@bbs.darktech.org> In other words this is a known bug that will be fixed in the final version? Gili Trent Jarvi wrote: > > >> When using RXTX-2.2pre2 I always get the following message: >> >> WARNING: RXTX Version mismatch >> Jar version = RXTX-2.2pre1 >> native lib Version = RXTX-2.2pre2 >> > > Yep. > > You should still be able to test it. > > -- > Trent Jarvi > tjarvi at qbang.org From cowwoc at bbs.darktech.org Sat Apr 4 16:57:34 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sat, 04 Apr 2009 18:57:34 -0400 Subject: [Rxtx] IOException: Underlying input stream returned zero bytes Message-ID: <49D7E5DE.2050405@bbs.darktech.org> Hi, There seems to be a bug in RXTX 2.2pre2's handling of InputStream timeouts. If you open a serial port without ever invoking enableReceiveTimeout() then invoking InputStream.read() will always return 0 bytes right away. If you wrap the InputStream and invoke BufferedReader.readline() you will get the following exception: java.io.IOException: Underlying input stream returned zero bytes at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:268) [na:1.6.0_14-ea] at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:306) [na:1.6.0_14-ea] at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:158) [na:1.6.0_14-ea] at java.io.InputStreamReader.read(InputStreamReader.java:167) [na:1.6.0_14-ea] at java.io.BufferedReader.fill(BufferedReader.java:136) [na:1.6.0_14-ea] at java.io.BufferedReader.readLine(BufferedReader.java:299) [na:1.6.0_14-ea] at java.io.BufferedReader.readLine(BufferedReader.java:362) [na:1.6.0_14-ea] [snip] If you enable a timeout, the exception will only occur after the timeout expires. In short, it looks like RXTX is using a default timeout of zero (I am expecting it to block forever). It looks like other people have run into this as well: http://forums.sun.com/thread.jspa?threadID=5165346&start=10&tstart=0 Please confirm whether this is a known bug. Thank you, Gili From tjarvi at qbang.org Sat Apr 4 17:27:19 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Apr 2009 17:27:19 -0600 (MDT) Subject: [Rxtx] IOException: Underlying input stream returned zero bytes In-Reply-To: <49D7E5DE.2050405@bbs.darktech.org> References: <49D7E5DE.2050405@bbs.darktech.org> Message-ID: On Sat, 4 Apr 2009, cowwoc wrote: > Hi, > > There seems to be a bug in RXTX 2.2pre2's handling of InputStream > timeouts. If you open a serial port without ever invoking > enableReceiveTimeout() then invoking InputStream.read() will always > return 0 bytes right away. If you wrap the InputStream and invoke > BufferedReader.readline() you will get the following exception: > > java.io.IOException: Underlying input stream returned zero bytes > at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:268) > [na:1.6.0_14-ea] > at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:306) > [na:1.6.0_14-ea] > at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:158) > [na:1.6.0_14-ea] > at java.io.InputStreamReader.read(InputStreamReader.java:167) > [na:1.6.0_14-ea] > at java.io.BufferedReader.fill(BufferedReader.java:136) > [na:1.6.0_14-ea] > at java.io.BufferedReader.readLine(BufferedReader.java:299) > [na:1.6.0_14-ea] > at java.io.BufferedReader.readLine(BufferedReader.java:362) > [na:1.6.0_14-ea] > [snip] > > If you enable a timeout, the exception will only occur after the > timeout expires. In short, it looks like RXTX is using a default timeout > of zero (I am expecting it to block forever). It looks like other people > have run into this as well: > http://forums.sun.com/thread.jspa?threadID=5165346&start=10&tstart=0 > > Please confirm whether this is a known bug. > Hi Gili I've known about it but was not sure if it was a bug or not. It looks like we can treat it as a bug if nio is throwing an exception. Timeout and Thresholds are well documented in javax.comm but I didn't recall seeing defaults. For that reason, I've encouraged people to set the threshold and timeout to what they expect. Another note about InputStream.read(void): I noticed that I don't use that function at all while looking at code coverage results. Keep your eye out for additional issues. -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Sat Apr 4 19:03:29 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sat, 04 Apr 2009 21:03:29 -0400 Subject: [Rxtx] IOException: Underlying input stream returned zero bytes In-Reply-To: References: <49D7E5DE.2050405@bbs.darktech.org> Message-ID: <49D80361.7020801@bbs.darktech.org> Trent Jarvi wrote: > For that reason, I've encouraged people to set the threshold and timeout > to what they expect. It doesn't help. There doesn't seem to be a way to disable the timeout, even if you invoke disableReceiveTimeout() explicitly. Let me know when you put in a fix and I will test it. Thanks, Gili From cowwoc at bbs.darktech.org Sat Apr 4 23:27:25 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 01:27:25 -0400 Subject: [Rxtx] Crash in termios.c:892 Message-ID: <49D8413D.7040105@bbs.darktech.org> I can reproduce a crash in RXTX 2.2 pre2 100% of the time using my application code, but I can't seem to bring it down to a minimal testcase. Here is what I see: - thread begins running - open com1 - close com1 - open com5 - leave com5 open - thread shuts down - repeat the same process in a new thread - crash occurs when trying to open com1. Crash disappears if I close() com5 in the previous thread. The output window contains the following: # # A fatal error has been detected by the Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x05475cf6, pid=6064, tid=5436 # # JRE version: 6.0_14-b04 # Java VM: Java HotSpot(TM) Client VM (14.0-b13 mixed mode, sharing windows-x86 ) # Problematic frame: # C [rxtxSerial.dll+0x5cf6] # # An error report file with more information is saved as: # C:\Users\Gili\Documents\foobar\source\hs_err_pid6064.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp Error 0x5 at ..\src\termios.c(892): Access is denied. # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # Please let me know if the crash dump is enough to track down this bug. Thank you, Gili -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: hs_err_pid6064.log Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20090405/7133a1ce/attachment.pl From cowwoc at bbs.darktech.org Sun Apr 5 00:24:19 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 02:24:19 -0400 Subject: [Rxtx] SerialPort.getName() is wrong Message-ID: <49D84E93.7050606@bbs.darktech.org> Sorry for all these emails but I keep on running into more issues. Here is what I noticed: - CommPortIdentifier.getPortIdentifier("COM5") returns a CommPortIdentifier where getName() == "COM5" - If, however, you invoke CommPortIdentifier.open() you get back a SerialPort where SerialPort.getName() is "//./COM5" I am expecting the name to remain consistent. "//./COM5" looks like an implementation detail and (as far as I can tell) it can't be used as an argument for any API method so it is somewhat useless. If getName() were to return "COM5" I could at least use it to get back the original CommPortIdentifier or compare against "known names" such as "COMx" or "LPTx". What do you think? Gili From tjarvi at qbang.org Sun Apr 5 10:18:42 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Apr 2009 10:18:42 -0600 (MDT) Subject: [Rxtx] SerialPort.getName() is wrong In-Reply-To: <49D84E93.7050606@bbs.darktech.org> References: <49D84E93.7050606@bbs.darktech.org> Message-ID: On Sun, 5 Apr 2009, cowwoc wrote: > > Sorry for all these emails but I keep on running into more issues. > Here is what I noticed: > > - CommPortIdentifier.getPortIdentifier("COM5") returns a > CommPortIdentifier where getName() == "COM5" > - If, however, you invoke CommPortIdentifier.open() you get back a > SerialPort where SerialPort.getName() is "//./COM5" > > I am expecting the name to remain consistent. "//./COM5" looks like > an implementation detail and (as far as I can tell) it can't be used as > an argument for any API method so it is somewhat useless. If getName() > were to return "COM5" I could at least use it to get back the original > CommPortIdentifier or compare against "known names" such as "COMx" or > "LPTx". What do you think? > Sure. If it itches enough you should be able to fix this in RXTXCommDriver.java. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Apr 5 10:27:58 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Apr 2009 10:27:58 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D8413D.7040105@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> Message-ID: On Sun, 5 Apr 2009, cowwoc wrote: > > I can reproduce a crash in RXTX 2.2 pre2 100% of the time using my > application code, but I can't seem to bring it down to a minimal testcase. > Here is what I see: > > - thread begins running > - open com1 > - close com1 > - open com5 > - leave com5 open > - thread shuts down > - repeat the same process in a new thread > - crash occurs when trying to open com1. Crash disappears if I close() com5 > in the previous thread. > > The output window contains the following: > > # > # A fatal error has been detected by the Java Runtime Environment: > # > # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x05475cf6, pid=6064, > tid=5436 > # > # JRE version: 6.0_14-b04 > # Java VM: Java HotSpot(TM) Client VM (14.0-b13 mixed mode, sharing > windows-x86 ) > # Problematic frame: > # C [rxtxSerial.dll+0x5cf6] > # > # An error report file with more information is saved as: > # C:\Users\Gili\Documents\foobar\source\hs_err_pid6064.log > # > # If you would like to submit a bug report, please visit: > # http://java.sun.com/webapps/bugreport/crash.jsp > Error 0x5 at ..\src\termios.c(892): Access is denied. > > > # The crash happened outside the Java Virtual Machine in native code. > # See problematic frame for where to report the bug. > # > > Please let me know if the crash dump is enough to track down this bug. > Hi Gili, You are responsible for cleaning up the serial ports when using threads. That said, if the thread did shut down, finalize should have been called if you are not passing the object around. See RXTXPort.java. protected void finalize() { if (debug) z.reportln( "RXTXPort:finalize()"); if( fd > 0 ) { if (debug) z.reportln( "RXTXPort:calling close()"); close(); } z.finalize(); } The exception is interesting. This is on Vista? Usually it just gives an open error when another process has the port. -- Trent Jarvi tjarvi at mathworks.com From cowwoc at bbs.darktech.org Sun Apr 5 10:35:55 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 12:35:55 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: References: <49D8413D.7040105@bbs.darktech.org> Message-ID: <49D8DDEB.5010908@bbs.darktech.org> Trent Jarvi wrote: > You are responsible for cleaning up the serial ports when using threads. > That said, if the thread did shut down, finalize should have been called > if you are not passing the object around. See RXTXPort.java. > > protected void finalize() > { > if (debug) > z.reportln( "RXTXPort:finalize()"); > if( fd > 0 ) > { > if (debug) > z.reportln( "RXTXPort:calling close()"); > close(); > } > z.finalize(); > } Two points: 1) One should never rely on finalizers because they may never run. 2) RXTX shouldn't cause the entire JVM to crash if I misuse the API. The native code should recover more gracefully. > The exception is interesting. This is on Vista? Usually it just gives > an open error when another process has the port. Yes, this is on Vista 64-bit. I'd really like to see this bug fixed. Is this code compilable under Visual Studio? If so, I can debug the problem on my end and send you a patch. Thanks, Gili From cowwoc at bbs.darktech.org Sun Apr 5 10:36:20 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 12:36:20 -0400 Subject: [Rxtx] SerialPort.getName() is wrong In-Reply-To: References: <49D84E93.7050606@bbs.darktech.org> Message-ID: <49D8DE04.6030306@bbs.darktech.org> Trent Jarvi wrote: >> I am expecting the name to remain consistent. "//./COM5" looks like >> an implementation detail and (as far as I can tell) it can't be used as >> an argument for any API method so it is somewhat useless. If getName() >> were to return "COM5" I could at least use it to get back the original >> CommPortIdentifier or compare against "known names" such as "COMx" or >> "LPTx". What do you think? >> > > Sure. > > If it itches enough you should be able to fix this in RXTXCommDriver.java. I'm not sure I understand. Are you saying that if I submit a patch you will commit it? Gili From tjarvi at qbang.org Sun Apr 5 10:46:23 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Apr 2009 10:46:23 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D8DDEB.5010908@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> Message-ID: On Sun, 5 Apr 2009, cowwoc wrote: > Trent Jarvi wrote: >> You are responsible for cleaning up the serial ports when using threads. >> That said, if the thread did shut down, finalize should have been called if >> you are not passing the object around. See RXTXPort.java. >> >> protected void finalize() >> { >> if (debug) >> z.reportln( "RXTXPort:finalize()"); >> if( fd > 0 ) >> { >> if (debug) >> z.reportln( "RXTXPort:calling close()"); >> close(); >> } >> z.finalize(); >> } > > Two points: > > 1) One should never rely on finalizers because they may never run. > 2) RXTX shouldn't cause the entire JVM to crash if I misuse the API. The > native code should recover more gracefully. > >> The exception is interesting. This is on Vista? Usually it just gives an >> open error when another process has the port. > > Yes, this is on Vista 64-bit. I'd really like to see this bug fixed. > Is this code compilable under Visual Studio? If so, I can debug the problem > on my end and send you a patch. > It will compile with the msvc cl.exe and nmake. See Makefile.msvc in the top level directory. You will need to adjust the JAVA_HOME variable. Also use the MSVC command prompt for x86_64 so cl and nmake are on your path. All the best, -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Apr 5 10:49:10 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Apr 2009 10:49:10 -0600 (MDT) Subject: [Rxtx] SerialPort.getName() is wrong In-Reply-To: <49D8DE04.6030306@bbs.darktech.org> References: <49D84E93.7050606@bbs.darktech.org> <49D8DE04.6030306@bbs.darktech.org> Message-ID: On Sun, 5 Apr 2009, cowwoc wrote: > Trent Jarvi wrote: >>> I am expecting the name to remain consistent. "//./COM5" looks like >>> an implementation detail and (as far as I can tell) it can't be used as >>> an argument for any API method so it is somewhat useless. If getName() >>> were to return "COM5" I could at least use it to get back the original >>> CommPortIdentifier or compare against "known names" such as "COMx" or >>> "LPTx". What do you think? >>> >> >> Sure. >> >> If it itches enough you should be able to fix this in RXTXCommDriver.java. > > I'm not sure I understand. Are you saying that if I submit a patch > you will commit it? > Hi Gili, Post a patch here and if nobody complains, we will commit it and give you credit. Yep. Other issues like changing the API to use java5 that may break existing apps are likely to run into objections but bug fixes usually get fixed just as you mention. -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Sun Apr 5 10:55:07 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 12:55:07 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> Message-ID: <49D8E26B.2040705@bbs.darktech.org> Trent Jarvi wrote: > It will compile with the msvc cl.exe and nmake. See Makefile.msvc in > the top level directory. You will need to adjust the JAVA_HOME > variable. Also use the MSVC command prompt for x86_64 so cl and nmake > are on your path. This is very odd. The CVS version of the code does not contain this file. Do you keep the latest code somewhere else? Gili From cowwoc at bbs.darktech.org Sun Apr 5 11:01:58 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 13:01:58 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D8E26B.2040705@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> Message-ID: <49D8E406.10708@bbs.darktech.org> cowwoc wrote: > Trent Jarvi wrote: >> It will compile with the msvc cl.exe and nmake. See Makefile.msvc in >> the top level directory. You will need to adjust the JAVA_HOME >> variable. Also use the MSVC command prompt for x86_64 so cl and nmake >> are on your path. > > This is very odd. The CVS version of the code does not contain this > file. Do you keep the latest code somewhere else? Okay I figured it out. CVS head is out of date, the "commapi-0-0-1" revision contains the correct files. Gili From tjarvi at qbang.org Sun Apr 5 11:05:43 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Apr 2009 11:05:43 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D8E26B.2040705@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> Message-ID: CVS HEAD is currently the rxtx 2.0 code. A branch was created long ago for 'experimental' gnu.io work. It just happens that the branch is what everyone uses now. checkout -r commapi-0-0-1 rxtx-devel will get the branch On Sun, 5 Apr 2009, cowwoc wrote: > Trent Jarvi wrote: >> It will compile with the msvc cl.exe and nmake. See Makefile.msvc in the >> top level directory. You will need to adjust the JAVA_HOME variable. Also >> use the MSVC command prompt for x86_64 so cl and nmake are on your path. > > This is very odd. The CVS version of the code does not contain this > file. Do you keep the latest code somewhere else? > > Gili > From cowwoc at bbs.darktech.org Sun Apr 5 14:50:47 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 16:50:47 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> Message-ID: <49D919A7.1070806@bbs.darktech.org> Okay, I tracked down the crash. It's being caused by YACK() using a 80-character buffer. The error message is longer than 80 characters, so _snprintf_s() crashes to avoid a buffer overflow. Please apply the attached patch and add the zipped up Visual Studio project directory. It's not perfect yet but it's a good start. Gili Trent Jarvi wrote: > > CVS HEAD is currently the rxtx 2.0 code. A branch was created long > ago for 'experimental' gnu.io work. It just happens that the branch > is what everyone uses now. > > checkout -r commapi-0-0-1 rxtx-devel > > will get the branch > > On Sun, 5 Apr 2009, cowwoc wrote: > >> Trent Jarvi wrote: >>> It will compile with the msvc cl.exe and nmake. See Makefile.msvc >>> in the top level directory. You will need to adjust the JAVA_HOME >>> variable. Also use the MSVC command prompt for x86_64 so cl and >>> nmake are on your path. >> >> This is very odd. The CVS version of the code does not contain >> this file. Do you keep the latest code somewhere else? >> >> Gili >> -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx-devel.patch Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20090405/d9b82962/attachment-0001.asc -------------- next part -------------- A non-text attachment was scrubbed... Name: Win32.zip Type: application/octet-stream Size: 17764 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20090405/d9b82962/attachment-0001.obj From cowwoc at bbs.darktech.org Sun Apr 5 15:22:01 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 17:22:01 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D919A7.1070806@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> <49D919A7.1070806@bbs.darktech.org> Message-ID: <49D920F9.6080702@bbs.darktech.org> My mistake. The problem in YACK is real, but it isn't the real cause of the crash. The crash is caused by termios.c line 1099: index->prev->next = port; because in my case "index->prev==0". I think the bug is that the code assumes that index will contain a minimum of two entries if we're inserting a previously closed fd. In my case, it only contains one. I'm not sure why you have this code branch (as opposed to appending to the end of index). Please take a look. Thanks, Gili cowwoc wrote: > > Okay, I tracked down the crash. It's being caused by YACK() using a > 80-character buffer. The error message is longer than 80 characters, so > _snprintf_s() crashes to avoid a buffer overflow. > > Please apply the attached patch and add the zipped up Visual Studio > project directory. It's not perfect yet but it's a good start. > > Gili > > Trent Jarvi wrote: >> >> CVS HEAD is currently the rxtx 2.0 code. A branch was created long >> ago for 'experimental' gnu.io work. It just happens that the branch >> is what everyone uses now. >> >> checkout -r commapi-0-0-1 rxtx-devel >> >> will get the branch >> >> On Sun, 5 Apr 2009, cowwoc wrote: >> >>> Trent Jarvi wrote: >>>> It will compile with the msvc cl.exe and nmake. See Makefile.msvc >>>> in the top level directory. You will need to adjust the JAVA_HOME >>>> variable. Also use the MSVC command prompt for x86_64 so cl and >>>> nmake are on your path. >>> >>> This is very odd. The CVS version of the code does not contain >>> this file. Do you keep the latest code somewhere else? >>> >>> Gili >>> From tjarvi at qbang.org Sun Apr 5 16:13:27 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Apr 2009 16:13:27 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D920F9.6080702@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> <49D919A7.1070806@bbs.darktech.org> <49D920F9.6080702@bbs.darktech.org> Message-ID: Hi Gili, Are you using the cvs version? I thought we fixed the linked list issues. A solution was posted to the list. Let me look at work tomorrow to see what I have. On Sun, 5 Apr 2009, cowwoc wrote: > > My mistake. The problem in YACK is real, but it isn't the real cause > of the crash. The crash is caused by termios.c line 1099: > > index->prev->next = port; > > because in my case "index->prev==0". I think the bug is that the code > assumes that index will contain a minimum of two entries if we're inserting a > previously closed fd. In my case, it only contains one. > > I'm not sure why you have this code branch (as opposed to appending > to the end of index). Please take a look. > > Thanks, > Gili > > cowwoc wrote: >> >> Okay, I tracked down the crash. It's being caused by YACK() using a >> 80-character buffer. The error message is longer than 80 characters, so >> _snprintf_s() crashes to avoid a buffer overflow. >> >> Please apply the attached patch and add the zipped up Visual Studio >> project directory. It's not perfect yet but it's a good start. >> >> Gili >> >> Trent Jarvi wrote: >>> >>> CVS HEAD is currently the rxtx 2.0 code. A branch was created long ago >>> for 'experimental' gnu.io work. It just happens that the branch is what >>> everyone uses now. >>> >>> checkout -r commapi-0-0-1 rxtx-devel >>> >>> will get the branch >>> >>> On Sun, 5 Apr 2009, cowwoc wrote: >>> >>>> Trent Jarvi wrote: >>>>> It will compile with the msvc cl.exe and nmake. See Makefile.msvc in >>>>> the top level directory. You will need to adjust the JAVA_HOME >>>>> variable. Also use the MSVC command prompt for x86_64 so cl and nmake >>>>> are on your path. >>>> >>>> This is very odd. The CVS version of the code does not contain this >>>> file. Do you keep the latest code somewhere else? >>>> >>>> Gili >>>> > From ilkka at myller.com Sun Apr 5 23:58:08 2009 From: ilkka at myller.com (Ilkka Myller) Date: Mon, 6 Apr 2009 08:58:08 +0300 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> <49D919A7.1070806@bbs.darktech.org> <49D920F9.6080702@bbs.darktech.org> Message-ID: <19779C97-E0C7-4E3D-B715-F84F50F00CE6@myller.com> Hi all, I've already submitted the patch to fix this issue in february: http://mailman.qbang.org/pipermail/rxtx/2009-February/3989441.html The patch fixes the mentioned doubly linked list handling in termios.c -- I Trent Jarvi kirjoitti 6.4.2009 kello 1.13: > > Hi Gili, > > Are you using the cvs version? I thought we fixed the linked list > issues. > A solution was posted to the list. Let me look at work tomorrow to > see > what I have. > > > > On Sun, 5 Apr 2009, cowwoc wrote: > >> >> My mistake. The problem in YACK is real, but it isn't the real cause >> of the crash. The crash is caused by termios.c line 1099: >> >> index->prev->next = port; >> >> because in my case "index->prev==0". I think the bug is that the >> code >> assumes that index will contain a minimum of two entries if we're >> inserting a >> previously closed fd. In my case, it only contains one. >> >> I'm not sure why you have this code branch (as opposed to appending >> to the end of index). Please take a look. >> >> Thanks, >> Gili >> >> cowwoc wrote: >>> >>> Okay, I tracked down the crash. It's being caused by YACK() >>> using a >>> 80-character buffer. The error message is longer than 80 >>> characters, so >>> _snprintf_s() crashes to avoid a buffer overflow. >>> >>> Please apply the attached patch and add the zipped up Visual >>> Studio >>> project directory. It's not perfect yet but it's a good start. >>> >>> Gili >>> >>> Trent Jarvi wrote: >>>> >>>> CVS HEAD is currently the rxtx 2.0 code. A branch was created >>>> long ago >>>> for 'experimental' gnu.io work. It just happens that the branch >>>> is what >>>> everyone uses now. >>>> >>>> checkout -r commapi-0-0-1 rxtx-devel >>>> >>>> will get the branch >>>> >>>> On Sun, 5 Apr 2009, cowwoc wrote: >>>> >>>>> Trent Jarvi wrote: >>>>>> It will compile with the msvc cl.exe and nmake. See >>>>>> Makefile.msvc in >>>>>> the top level directory. You will need to adjust the JAVA_HOME >>>>>> variable. Also use the MSVC command prompt for x86_64 so cl and >>>>>> nmake >>>>>> are on your path. >>>>> >>>>> This is very odd. The CVS version of the code does not >>>>> contain this >>>>> file. Do you keep the latest code somewhere else? >>>>> >>>>> Gili >>>>> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Steffen.DETTMER at ingenico.com Mon Apr 6 02:53:47 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 6 Apr 2009 10:53:47 +0200 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D919A7.1070806@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> <49D919A7.1070806@bbs.darktech.org> Message-ID: <20090406085347.GM8289@elberon.bln.de.ingenico.com> Hi, just two minor details, first about the errno change, I though #include extern int errno; is correct (POSIX.1) - why this change? second about the log message, I think the maximum length could be limited and the return value of malloc must be checked for != NULL before using. Should it be _snprintf_s( message, 80, _TRUNCATE, "Error 0x%x at %s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); (I know that MS-CRT _snprintf does not guarantee to have a final EOS, but I think _snprintf_s with _TRUNCATE does so?). If it is known that truncation may happen maybe sizeof[message] could be increased; maybe using some %.20s could be used avoiding __FILE__ including big pathes to a message where all the message had been cut-off. To have it portable I think it could be: /* generally: */ #if defined(_MSC_VER) # define snprintf _snprintf #endif snprintf(message, sizeof(message), "Error 0x%x at %.20s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); message[sizeof(message)-1] = '\0'; /* needed for MS CRT snprintf */ (for length and size parameter I think size_t could be an option, but on several platforms, including MS-CRT and older glibc, there is no %z, unfortunately) oki, Steffen * cowwoc wrote on Sun, Apr 05, 2009 at 16:50 -0400: > > Okay, I tracked down the crash. It's being caused by YACK() using a > 80-character buffer. The error message is longer than 80 characters, so > _snprintf_s() crashes to avoid a buffer overflow. > > Please apply the attached patch and add the zipped up Visual Studio > project directory. It's not perfect yet but it's a good start. > > Gili > > Trent Jarvi wrote: > > > >CVS HEAD is currently the rxtx 2.0 code. A branch was created long > >ago for 'experimental' gnu.io work. It just happens that the branch > >is what everyone uses now. > > > >checkout -r commapi-0-0-1 rxtx-devel > > > >will get the branch > > > >On Sun, 5 Apr 2009, cowwoc wrote: > > > >>Trent Jarvi wrote: > >>>It will compile with the msvc cl.exe and nmake. See Makefile.msvc > >>>in the top level directory. You will need to adjust the JAVA_HOME > >>>variable. Also use the MSVC command prompt for x86_64 so cl and > >>>nmake are on your path. > >> > >> This is very odd. The CVS version of the code does not contain > >>this file. Do you keep the latest code somewhere else? > >> > >>Gili > >> > Index: ParallelImp.c > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/ParallelImp.c,v > retrieving revision 1.15.2.36 > diff -u -r1.15.2.36 ParallelImp.c > --- ParallelImp.c 11 Feb 2009 01:04:19 -0000 1.15.2.36 > +++ ParallelImp.c 5 Apr 2009 17:55:23 -0000 > @@ -119,7 +119,7 @@ > # include > #endif > > -extern int errno; > +_CRTIMP extern int * __cdecl _errno(void); > > #include "ParallelImp.h" > > @@ -181,8 +181,6 @@ > > #if defined (WIN32) > > -#define CTL_CODE( DeviceType, Function, Method, Access ) (((DeviceType) << 16) | ((Access) << 14) | ((Function) << 2) | (Method)) > - > #define FILE_DEVICE_PARALLEL_PORT 0x00000016 > #define METHOD_BUFFERED 0 > #define FILE_ANY_ACCESS 0 > @@ -253,7 +251,6 @@ > jobject jobj) > { > int fd = get_java_var( env, jobj,"fd","I" ); > - int status; > #if defined (__linux__) > ioctl(fd, LPGETSTATUS, &status); > #elif defined (WIN32) > Index: SerialImp.c > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v > retrieving revision 1.46.2.203 > diff -u -r1.46.2.203 SerialImp.c > --- SerialImp.c 19 Mar 2009 03:27:48 -0000 1.46.2.203 > +++ SerialImp.c 5 Apr 2009 17:49:48 -0000 > @@ -147,7 +147,7 @@ > #include > #endif /* LIBLOCKDEV */ > > -extern int errno; > +_CRTIMP extern int * __cdecl _errno(void); > > #include "SerialImp.h" > > Index: termios.c > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/termios.c,v > retrieving revision 1.9.2.62 > diff -u -r1.9.2.62 termios.c > --- termios.c 13 Jan 2009 03:08:55 -0000 1.9.2.62 > +++ termios.c 5 Apr 2009 17:54:09 -0000 > @@ -88,7 +88,7 @@ > #define SIGIO 0 > > int my_errno; > -extern int errno; > +_CRTIMP extern int * __cdecl _errno(void); > struct termios_list > { > char filename[80]; > @@ -1350,7 +1350,7 @@ > In that case use EAGAIN. See SerialImp.c:testRead() > ----------------------------------------------------------*/ > > -int serial_read( int fd, void *vb, int size ) > +int serial_read( int fd, void *vb, unsigned int size ) > { > long start, now; > unsigned long nBytes = 0, total = 0, error; > Index: win32termios.h > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/win32termios.h,v > retrieving revision 1.5.2.34 > diff -u -r1.5.2.34 win32termios.h > --- win32termios.h 5 Feb 2009 01:25:05 -0000 1.5.2.34 > +++ win32termios.h 5 Apr 2009 20:29:30 -0000 > @@ -60,6 +60,7 @@ > #include > #include > #include > +#include > #ifdef TRACE > #define ENTER(x) report("entering "x" \n"); > #define LEAVE(x) report("leaving "x" \n"); > @@ -70,8 +71,9 @@ > #if defined(_MSC_VER) > #define YACK() \ > { \ > - char *allocTextBuf, message[80]; \ > - unsigned long nChars; \ > + char *allocTextBuf, *message; \ > + const unsigned short longestNumber = 20; \ > + unsigned long nChars, len; \ > unsigned int errorCode = GetLastError(); \ > nChars = FormatMessage ( \ > FORMAT_MESSAGE_ALLOCATE_BUFFER | \ > @@ -82,8 +84,12 @@ > (LPSTR)&allocTextBuf, \ > 16, \ > NULL ); \ > - _snprintf_s( message, 80, 80, "Error 0x%x at %s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); \ > + len = strlen("Error 0x") + longestNumber + strlen(" at ") + strlen(__FILE__) + longestNumber + \ > + strlen(": ") + ((nChars+1) * sizeof(TCHAR)) + 1; \ > + message = malloc(len); \ > + _snprintf_s( message, len, len - 1, "Error 0x%x at %s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); \ > report_error( message ); \ > + free(message); \ > LocalFree(allocTextBuf); \ > Sleep(1); \ > } > @@ -173,7 +179,7 @@ > int serial_test( char * ); > int serial_open(const char *File, int flags, ... ); > int serial_close(int fd); > -int serial_read(int fd, void *b, int size); > +int serial_read(int fd, void *b, unsigned int size); > int serial_write(int fd, char *Str, int length); > /* > * lcc winsock.h conflicts > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx End of message. ------------------------------------------------------------------->8======= About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From cowwoc at bbs.darktech.org Wed Apr 1 22:05:13 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Thu, 02 Apr 2009 00:05:13 -0400 Subject: [Rxtx] Windows 64-bit support? Message-ID: <49D43979.4050702@bbs.darktech.org> Hi, I'd like to run RXTX under the Windows 64-bit JVM. Are there plans to release an official 64-bit version anytime soon? Gili From bill7007 at gmail.com Thu Apr 2 16:01:17 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Thu, 2 Apr 2009 18:01:17 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel Message-ID: Hi, I have an rxtx serial application that used to work reliably until I had to move it to newer hardware and kernel. Now, the application sometimes hangs near first port use. When it does hang, it can be released by starting a second copy of the application which is locked out of the ports but does release the first process. Upgraded from rxtx-2.1-7-r2 to rxtx-2.2pre2 but still hangs. Tried to rebuild on the target machine and ran into the 'UTS_RELEASE' undeclared problem so holding on that approach. Recompiled OK on a 2.6.9-42.0.3.ELsmp system. Debug messages were turned on using: "./configure --enable-DEBUG" and modified RXTXPort.java with: "debug = true;" "z = new Zystem(Zystem.PRINT_MODE);" Below is capture of the application with debugging enabled. It show the application hang point, and the second application's printout at the release point. (pre3 is the locally modified version of pre2) Any suggestions on how to pin this down further? Thanks, +BillJ $ java -version java version "1.5.0_06" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05) Java HotSpot(TM) Client VM (build 1.5.0_06-b05, mixed mode, sharing) $ uname -a Linux qms4 2.6.18-92.1.6.el5 #1 SMP Wed Jun 25 13:49:24 EDT 2008 i686 i686 i386 GNU/Linux ***CAPTURE: [qms at qms4 ~]$ ./qms/ScriptFiles/startup.sh Thu Apr 02 13:35:45 EDT 2009:Setting Log File to:/home/qms/qms/QMS.log Thu Apr 02 13:35:45 EDT 2009:TSettings.HandleIni:ReUsing Ini file:/home/qms/qms/qms.properties WARNING: RXTX Version mismatch Jar version = RXTX-2.2pre2 native lib Version = RXTX-2.2pre3 fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB2 fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB1 fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB0 fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile RXTXPort {} RXTX WARNING: This library was compiled to run with OS release 2.4.20 and you are currently running OS release 2.6.18-92.1.6.el5. In some cases this can be a problem. Try recompiling RXTX if you notice strange behavior. If you just compiled RXTX make sure /usr/include/linux is a symbolic link to the include files that came with the kernel source and not an older copy. press enter to continue RXTXPort:RXTXPort(/dev/ttyUSB2) called fhs_lock: creating lockfile: 10127 open: locking worked for /dev/ttyUSB2 open: fd returned is 8 RXTXPort:MontitorThread:MonitorThread() RXTXPort:MontitorThread:run() has_line_status_register_acess: Port does not support TIOCSERGETLSR init_threads: get eis init_threads: set eis init_threads: stop RXTXPort:RXTXPort(/dev/ttyUSB2) returns with fd = 8 RXTXPort:setSerialPortParams(38400 8 1 0) called RXTXPort:setSerialPortParams(38400 8 1 0) returning RXTXPort:getInputStream() called and returning Thu Apr 02 13:36:02 EDT 2009:TSerial[22]:Using Port:/dev/ttyUSB2 RXTXPort:getOutputStream() called and returning Thu Apr 02 13:36:02 EDT 2009:TSerial[22].Transmit:TN Entering RXTXPort:SerialOutputStream:write(4) writeArray() Leaving RXTXPort:SerialOutputStream:write(4) RXTXPort:SerialOutputStream:flush() enter RXTXPort:SerialOutputStream:flush() leave Thu Apr 02 13:36:02 EDT 2009:TSerial[22].Transmit:RV Entering RXTXPort:SerialOutputStream:write(4) writeArray() Leaving RXTXPort:SerialOutputStream:write(4) RXTXPort:SerialOutputStream:flush() enter RXTXPort:SerialInputStream:read(8192 0 8192) called ***FIRST PROCESS HANGS HERE ***THEN PROCEEDS AFTER SECOND PROCESS STARTS RXTXPort:SerialOutputStream:flush() leave Thu Apr 02 13:41:29 EDT 2009:TSerial[22].Transmit:IH9 Entering RXTXPort:SerialOutputStream:write(5) writeArray() Leaving RXTXPort:SerialOutputStream:write(5) RXTXPort:SerialOutputStream:flush() enter RXTXPort:SerialOutputStream:flush() leave Thu Apr 02 13:41:29 EDT 2009:TSerial[22].Transmit:IL11 ***END CAPTURE ***CAPTURE SECOND PROCESS FAILS OPEN [qms at qms4 ~]$ ./qms/ScriptFiles/startup.sh Thu Apr 02 13:41:27 EDT 2009:Setting Log File to:/home/qms/qms/QMS.log Thu Apr 02 13:41:27 EDT 2009:TSettings.HandleIni:ReUsing Ini file:/home/qms/qms/qms.properties WARNING: RXTX Version mismatch Jar version = RXTX-2.2pre2 native lib Version = RXTX-2.2pre3 fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB2: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB1: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB0: File exists fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB2: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB1: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB0: File exists fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile Thu Apr 02 13:41:30 EDT 2009:TIOBoard: java.io.IOException: java.io.IOException: TSerial[22]: Open Failed ***END CAPTURE -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090402/c66f8d70/attachment-0005.html From netbeans at gatworks.com Thu Apr 2 17:15:04 2009 From: netbeans at gatworks.com (U. George) Date: Thu, 02 Apr 2009 19:15:04 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: Message-ID: <49D546F8.20807@gatworks.com> > "z = new Zystem(Zystem.PRINT_MODE);" > Below is capture of the application with debugging enabled. It show > the application hang point, and the second application's printout at the > release point. (pre3 is the locally modified version of pre2) > Any suggestions on how to pin this down further? > Thanks, > +BillJ When perceived runability is hung, try a ^\ ( control \) on console. This gets the JVM to dump the stacks of all the java threads. If you know the thread that is stuck, then u can see what java statement its stuck at. From tjarvi at qbang.org Thu Apr 2 19:25:17 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 2 Apr 2009 19:25:17 -0600 (MDT) Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: <49D546F8.20807@gatworks.com> References: <49D546F8.20807@gatworks.com> Message-ID: On Thu, 2 Apr 2009, U. George wrote: >> "z = new Zystem(Zystem.PRINT_MODE);" >> Below is capture of the application with debugging enabled. It show >> the application hang point, and the second application's printout at the >> release point. (pre3 is the locally modified version of pre2) >> Any suggestions on how to pin this down further? >> Thanks, >> +BillJ > > When perceived runability is hung, try a ^\ ( control \) on console. > This gets the JVM to dump the stacks of all the java threads. > If you know the thread that is stuck, then u can see what java statement > its stuck at. I've also noticed some linux systems hanging with open/read/write and saw kacpid storms. I need to look at it more but did observe kacpid consuming a core and not returning to a normal state for a significant period of time. It was easy to observe from top sorted by CPU usage. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Apr 2 19:26:18 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 2 Apr 2009 19:26:18 -0600 (MDT) Subject: [Rxtx] Windows 64-bit support? In-Reply-To: <49D43979.4050702@bbs.darktech.org> References: <49D43979.4050702@bbs.darktech.org> Message-ID: On Thu, 2 Apr 2009, cowwoc wrote: > Hi, > > I'd like to run RXTX under the Windows 64-bit JVM. Are there plans > to release an official 64-bit version anytime soon? > It is in the prerelease and will be in the final release. I'm pushing it through as fast as I can in my free time. -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Thu Apr 2 22:57:34 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Fri, 03 Apr 2009 00:57:34 -0400 Subject: [Rxtx] Missing documentation In-Reply-To: References: <49D43979.4050702@bbs.darktech.org> Message-ID: <49D5973E.4050400@bbs.darktech.org> Hi, I noticed that RXTX 2.1 drops javax.comm support in favor of gnu.io. I have one major problem with this: the gui.io.* documentation is very poor. Many classes and methods have no Javadoc at all which makes them difficult to use. Please fix this for the final release. Thank you, Gili From alex.sas at freemail.hu Fri Apr 3 01:36:54 2009 From: alex.sas at freemail.hu (Sas Alex) Date: Fri, 3 Apr 2009 09:36:54 +0200 (CEST) Subject: [Rxtx] Serial port false reads Message-ID: Hi all, On Windows XP, using rxtx-2.1-7-r2 I have a program communicating on a serial line like the following (excerpt): { os.write(command); os.flush(); // Thread.sleep(period); // read response while(is.available() > 0) { is.read() } } If there is a sleep between the os.flush and the reading cycle the correct answer is received. Otherwise (sometimes) there are extra, erronous characters at the beginning of the answer, but the correct answer (according to the protocol) also arrives, afterwards. Is this a normal behaviour, one should wait before the read? If yes, is there a way to determine the minimum amount of time to wait for? Serial port params are: 9600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE. Thank you in advance, Alex ________________________________________________________ El?foglal?si akci? meghosszabb?tva! Korfui ?d?l?s m?r 56.910 Ft-t?l. http://www.budavartours.hu/gorogorszag/?utm_campaign=origo&utm_source=freemail_kimeno_090403&utm_medium=ct&utm_content=korfu_elofoglalasi_akcio#reg_Korfu -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090403/8f3650ea/attachment-0005.html From bill7007 at gmail.com Fri Apr 3 16:15:30 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Fri, 3 Apr 2009 18:15:30 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: <49D546F8.20807@gatworks.com> Message-ID: > When perceived runability is hung, try a ^\ ( control \) on console. >> This gets the JVM to dump the stacks of all the java threads. > > Good idea... A thread dump is below, it looks like only some system threads are in wait state which is probably normal. The "main" thread is stopped writing the first data out the serial port which should complete but its has stopped at: at gnu.io.RXTXPort.nativeDrain(Native Method) It show its state as runnable though. There is another thread, "SerialReader_22", that is waiting to read any data on the same port. I'll bring the app up under Netbeans debugger next. >> > I've also noticed some linux systems hanging with open/read/write and saw > kacpid storms. No CPU use going when it hangs, acts like a deadlock. THREAD DUMP AT HANG: Entering RXTXPort:SerialOutputStream:write(4) writeArray() Leaving RXTXPort:SerialOutputStream:write(4) RXTXPort:SerialOutputStream:flush() enter RXTXPort:SerialInputStream:read(8192 0 8192) called Full thread dump Java HotSpot(TM) Client VM (1.5.0_06-b05 mixed mode, sharing): "SerialReader_22" daemon prio=1 tid=0x087abf38 nid=0x3c8b runnable [0xb1a43000..0xb1a43f30] at gnu.io.RXTXPort.readArray(Native Method) at gnu.io.RXTXPort$SerialInputStream.read(RXTXPort.java:1454) - locked <0x88ca55b8> (a gnu.io.RXTXPort$SerialInputStream) at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:411) at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) - locked <0x88cab378> (a java.io.InputStreamReader) at java.io.InputStreamReader.read(InputStreamReader.java:167) at java.io.BufferedReader.fill(BufferedReader.java:136) at java.io.BufferedReader.readLine(BufferedReader.java:299) - locked <0x88cab378> (a java.io.InputStreamReader) at java.io.BufferedReader.readLine(BufferedReader.java:362) at qms.TSerialPort$SerialRead.run(TSerialPort.java:268) at java.lang.Thread.run(Thread.java:595) "Thread-1" prio=1 tid=0x08a43360 nid=0x3c8a runnable [0xb1ac4000..0xb1ac4db0] at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1641) "AWT-XAWT" daemon prio=1 tid=0x08acc848 nid=0x3c87 runnable [0xb1b45000..0xb1b45e30] at sun.awt.X11.XToolkit.waitForEvents(Native Method) at sun.awt.X11.XToolkit.run(XToolkit.java:463) at sun.awt.X11.XToolkit.run(XToolkit.java:438) at java.lang.Thread.run(Thread.java:595) "Java2D Disposer" daemon prio=1 tid=0x08ab9d30 nid=0x3c86 in Object.wait() [0xb1bc6000..0xb1bc70b0] at java.lang.Object.wait(Native Method) - waiting on <0x8917b110> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:116) - locked <0x8917b110> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:132) at sun.java2d.Disposer.run(Disposer.java:107) at java.lang.Thread.run(Thread.java:595) "Low Memory Detector" daemon prio=1 tid=0x087bea68 nid=0x3c84 runnable [0x00000000..0x00000000] "CompilerThread0" daemon prio=1 tid=0x087bd4c0 nid=0x3c83 waiting on condition [0x00000000..0xb23a7a18] "Signal Dispatcher" daemon prio=1 tid=0x087bc520 nid=0x3c82 runnable [0x00000000..0x00000000] "Finalizer" daemon prio=1 tid=0x087b5710 nid=0x3c81 in Object.wait() [0xb26a9000..0xb26a9f30] at java.lang.Object.wait(Native Method) - waiting on <0x8914a770> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:116) - locked <0x8914a770> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:132) at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159) "Reference Handler" daemon prio=1 tid=0x087b49c8 nid=0x3c80 in Object.wait() [0xb272a000..0xb272adb0] at java.lang.Object.wait(Native Method) - waiting on <0x8914a7f0> (a java.lang.ref.Reference$Lock) at java.lang.Object.wait(Object.java:474) at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116) - locked <0x8914a7f0> (a java.lang.ref.Reference$Lock) "main" prio=1 tid=0x08777b88 nid=0x3c7e runnable [0xbffa7000..0xbffa74f8] at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1248) at qms.TSerialPort.Transmit(TSerialPort.java:192) - locked <0x88c99a68> (a qms.TSerialPort) at qms.TIOBoard.GetIOBoardVersion(TIOBoard.java:168) at qms.TIOBoard.(TIOBoard.java:73) at qms.TQMS.(TQMS.java:47) at qms.MainForm.(MainForm.java:2076) at qms.MainForm.main(MainForm.java:2099) "VM Thread" prio=1 tid=0x087b1e20 nid=0x3c7f runnable "VM Periodic Task Thread" prio=1 tid=0x087bff50 nid=0x3c85 waiting on condition -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090403/20b7bca4/attachment-0004.html From Martin.Oberhuber at windriver.com Fri Apr 3 16:23:43 2009 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Sat, 4 Apr 2009 00:23:43 +0200 Subject: [Rxtx] Missing documentation In-Reply-To: <49D5973E.4050400@bbs.darktech.org> References: <49D43979.4050702@bbs.darktech.org> <49D5973E.4050400@bbs.darktech.org> Message-ID: <460801A4097E3D4CA04CC64EE648584809C8BD6F@ism-mail03.corp.ad.wrs.com> Hello Gili, The classes in the gnu.io namespace are designed to work exactly as their counterparts in the javax.comm namespace. Therefore, if you just take the javax.comm Javadocs that's what you want. Unfortunately I don't think we can just copy & paste the javax.comm Javadocs into RXTX due to license restrictions. I guess that's the main reason why RXTX is not (yet) Javadoc'd as extensively as it should be. Actually, writing Javadocs from scratch WITHOUT referencing the wording of the Sun Javadocs is not that easy. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of cowwoc > Sent: Freitag, 03. April 2009 06:58 > To: rxtx at qbang.org > Subject: [Rxtx] Missing documentation > > Hi, > > I noticed that RXTX 2.1 drops javax.comm support in favor > of gnu.io. > I have one major problem with this: the gui.io.* > documentation is very > poor. Many classes and methods have no Javadoc at all which > makes them > difficult to use. Please fix this for the final release. > > Thank you, > Gili > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Fri Apr 3 16:54:50 2009 From: netbeans at gatworks.com (U. George) Date: Fri, 03 Apr 2009 18:54:50 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: <49D546F8.20807@gatworks.com> Message-ID: <49D693BA.8060909@gatworks.com> I would have tried 2 or 3 "^\" . If things are stuck, then all will be at same 'java' instruction. If thread is moving, then one of the snapshots would be different. I *think* flushing/draining wont return until the kernel buffers to device have been accepted by device. Stuck/paused device? Bill Johnson wrote: > > > > > When perceived runability is hung, try a ^\ ( control \) on console. > This gets the JVM to dump the stacks of all the java threads. > > > Good idea... A thread dump is below, it looks like only some system > threads are in wait state which is prob From cowwoc at bbs.darktech.org Fri Apr 3 17:45:09 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Fri, 03 Apr 2009 19:45:09 -0400 Subject: [Rxtx] Missing documentation In-Reply-To: <460801A4097E3D4CA04CC64EE648584809C8BD6F@ism-mail03.corp.ad.wrs.com> References: <49D43979.4050702@bbs.darktech.org> <49D5973E.4050400@bbs.darktech.org> <460801A4097E3D4CA04CC64EE648584809C8BD6F@ism-mail03.corp.ad.wrs.com> Message-ID: <49D69F85.3030804@bbs.darktech.org> You could always send Sun a formal email and ask for permission to copy their Javadoc. I doubt they would give you problems. Gili Oberhuber, Martin wrote: > Hello Gili, > > The classes in the gnu.io namespace are designed to work exactly > as their counterparts in the javax.comm namespace. Therefore, > if you just take the javax.comm Javadocs that's what you want. > > Unfortunately I don't think we can just copy & paste the > javax.comm Javadocs into RXTX due to license restrictions. > > I guess that's the main reason why RXTX is not (yet) Javadoc'd > as extensively as it should be. Actually, writing Javadocs > from scratch WITHOUT referencing the wording of the Sun > Javadocs is not that easy. > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] >> On Behalf Of cowwoc >> Sent: Freitag, 03. April 2009 06:58 >> To: rxtx at qbang.org >> Subject: [Rxtx] Missing documentation >> >> Hi, >> >> I noticed that RXTX 2.1 drops javax.comm support in favor >> of gnu.io. >> I have one major problem with this: the gui.io.* >> documentation is very >> poor. Many classes and methods have no Javadoc at all which >> makes them >> difficult to use. Please fix this for the final release. >> >> Thank you, >> Gili >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> From cowwoc at bbs.darktech.org Sat Apr 4 15:13:38 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sat, 04 Apr 2009 17:13:38 -0400 Subject: [Rxtx] Java5 support Message-ID: <49D7CD82.1040904@bbs.darktech.org> Now that you dropped javax.comm support, how about improving the API by replacing Enumation by Iterator, int by enum, and using Generics? It would improve the usability of the API. Gili From cowwoc at bbs.darktech.org Sat Apr 4 16:12:13 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sat, 04 Apr 2009 18:12:13 -0400 Subject: [Rxtx] RXTX Version mismatch in 2.2pre2 Message-ID: <49D7DB3D.5040008@bbs.darktech.org> When using RXTX-2.2pre2 I always get the following message: WARNING: RXTX Version mismatch Jar version = RXTX-2.2pre1 native lib Version = RXTX-2.2pre2 I have double checked that I am using the correct Jar file. Is this a known bug in pre2? Gili From tjarvi at qbang.org Sat Apr 4 16:48:53 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Apr 2009 16:48:53 -0600 (MDT) Subject: [Rxtx] RXTX Version mismatch in 2.2pre2 In-Reply-To: <49D7DB3D.5040008@bbs.darktech.org> References: <49D7DB3D.5040008@bbs.darktech.org> Message-ID: > When using RXTX-2.2pre2 I always get the following message: > > WARNING: RXTX Version mismatch > Jar version = RXTX-2.2pre1 > native lib Version = RXTX-2.2pre2 > Yep. You should still be able to test it. -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Sat Apr 4 16:50:43 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sat, 04 Apr 2009 18:50:43 -0400 Subject: [Rxtx] RXTX Version mismatch in 2.2pre2 In-Reply-To: References: <49D7DB3D.5040008@bbs.darktech.org> Message-ID: <49D7E443.9070404@bbs.darktech.org> In other words this is a known bug that will be fixed in the final version? Gili Trent Jarvi wrote: > > >> When using RXTX-2.2pre2 I always get the following message: >> >> WARNING: RXTX Version mismatch >> Jar version = RXTX-2.2pre1 >> native lib Version = RXTX-2.2pre2 >> > > Yep. > > You should still be able to test it. > > -- > Trent Jarvi > tjarvi at qbang.org From cowwoc at bbs.darktech.org Sat Apr 4 16:57:34 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sat, 04 Apr 2009 18:57:34 -0400 Subject: [Rxtx] IOException: Underlying input stream returned zero bytes Message-ID: <49D7E5DE.2050405@bbs.darktech.org> Hi, There seems to be a bug in RXTX 2.2pre2's handling of InputStream timeouts. If you open a serial port without ever invoking enableReceiveTimeout() then invoking InputStream.read() will always return 0 bytes right away. If you wrap the InputStream and invoke BufferedReader.readline() you will get the following exception: java.io.IOException: Underlying input stream returned zero bytes at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:268) [na:1.6.0_14-ea] at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:306) [na:1.6.0_14-ea] at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:158) [na:1.6.0_14-ea] at java.io.InputStreamReader.read(InputStreamReader.java:167) [na:1.6.0_14-ea] at java.io.BufferedReader.fill(BufferedReader.java:136) [na:1.6.0_14-ea] at java.io.BufferedReader.readLine(BufferedReader.java:299) [na:1.6.0_14-ea] at java.io.BufferedReader.readLine(BufferedReader.java:362) [na:1.6.0_14-ea] [snip] If you enable a timeout, the exception will only occur after the timeout expires. In short, it looks like RXTX is using a default timeout of zero (I am expecting it to block forever). It looks like other people have run into this as well: http://forums.sun.com/thread.jspa?threadID=5165346&start=10&tstart=0 Please confirm whether this is a known bug. Thank you, Gili From tjarvi at qbang.org Sat Apr 4 17:27:19 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Apr 2009 17:27:19 -0600 (MDT) Subject: [Rxtx] IOException: Underlying input stream returned zero bytes In-Reply-To: <49D7E5DE.2050405@bbs.darktech.org> References: <49D7E5DE.2050405@bbs.darktech.org> Message-ID: On Sat, 4 Apr 2009, cowwoc wrote: > Hi, > > There seems to be a bug in RXTX 2.2pre2's handling of InputStream > timeouts. If you open a serial port without ever invoking > enableReceiveTimeout() then invoking InputStream.read() will always > return 0 bytes right away. If you wrap the InputStream and invoke > BufferedReader.readline() you will get the following exception: > > java.io.IOException: Underlying input stream returned zero bytes > at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:268) > [na:1.6.0_14-ea] > at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:306) > [na:1.6.0_14-ea] > at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:158) > [na:1.6.0_14-ea] > at java.io.InputStreamReader.read(InputStreamReader.java:167) > [na:1.6.0_14-ea] > at java.io.BufferedReader.fill(BufferedReader.java:136) > [na:1.6.0_14-ea] > at java.io.BufferedReader.readLine(BufferedReader.java:299) > [na:1.6.0_14-ea] > at java.io.BufferedReader.readLine(BufferedReader.java:362) > [na:1.6.0_14-ea] > [snip] > > If you enable a timeout, the exception will only occur after the > timeout expires. In short, it looks like RXTX is using a default timeout > of zero (I am expecting it to block forever). It looks like other people > have run into this as well: > http://forums.sun.com/thread.jspa?threadID=5165346&start=10&tstart=0 > > Please confirm whether this is a known bug. > Hi Gili I've known about it but was not sure if it was a bug or not. It looks like we can treat it as a bug if nio is throwing an exception. Timeout and Thresholds are well documented in javax.comm but I didn't recall seeing defaults. For that reason, I've encouraged people to set the threshold and timeout to what they expect. Another note about InputStream.read(void): I noticed that I don't use that function at all while looking at code coverage results. Keep your eye out for additional issues. -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Sat Apr 4 19:03:29 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sat, 04 Apr 2009 21:03:29 -0400 Subject: [Rxtx] IOException: Underlying input stream returned zero bytes In-Reply-To: References: <49D7E5DE.2050405@bbs.darktech.org> Message-ID: <49D80361.7020801@bbs.darktech.org> Trent Jarvi wrote: > For that reason, I've encouraged people to set the threshold and timeout > to what they expect. It doesn't help. There doesn't seem to be a way to disable the timeout, even if you invoke disableReceiveTimeout() explicitly. Let me know when you put in a fix and I will test it. Thanks, Gili From cowwoc at bbs.darktech.org Sat Apr 4 23:27:25 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 01:27:25 -0400 Subject: [Rxtx] Crash in termios.c:892 Message-ID: <49D8413D.7040105@bbs.darktech.org> I can reproduce a crash in RXTX 2.2 pre2 100% of the time using my application code, but I can't seem to bring it down to a minimal testcase. Here is what I see: - thread begins running - open com1 - close com1 - open com5 - leave com5 open - thread shuts down - repeat the same process in a new thread - crash occurs when trying to open com1. Crash disappears if I close() com5 in the previous thread. The output window contains the following: # # A fatal error has been detected by the Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x05475cf6, pid=6064, tid=5436 # # JRE version: 6.0_14-b04 # Java VM: Java HotSpot(TM) Client VM (14.0-b13 mixed mode, sharing windows-x86 ) # Problematic frame: # C [rxtxSerial.dll+0x5cf6] # # An error report file with more information is saved as: # C:\Users\Gili\Documents\foobar\source\hs_err_pid6064.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp Error 0x5 at ..\src\termios.c(892): Access is denied. # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # Please let me know if the crash dump is enough to track down this bug. Thank you, Gili -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: hs_err_pid6064.log Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20090405/7133a1ce/attachment-0001.pl From cowwoc at bbs.darktech.org Sun Apr 5 00:24:19 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 02:24:19 -0400 Subject: [Rxtx] SerialPort.getName() is wrong Message-ID: <49D84E93.7050606@bbs.darktech.org> Sorry for all these emails but I keep on running into more issues. Here is what I noticed: - CommPortIdentifier.getPortIdentifier("COM5") returns a CommPortIdentifier where getName() == "COM5" - If, however, you invoke CommPortIdentifier.open() you get back a SerialPort where SerialPort.getName() is "//./COM5" I am expecting the name to remain consistent. "//./COM5" looks like an implementation detail and (as far as I can tell) it can't be used as an argument for any API method so it is somewhat useless. If getName() were to return "COM5" I could at least use it to get back the original CommPortIdentifier or compare against "known names" such as "COMx" or "LPTx". What do you think? Gili From tjarvi at qbang.org Sun Apr 5 10:18:42 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Apr 2009 10:18:42 -0600 (MDT) Subject: [Rxtx] SerialPort.getName() is wrong In-Reply-To: <49D84E93.7050606@bbs.darktech.org> References: <49D84E93.7050606@bbs.darktech.org> Message-ID: On Sun, 5 Apr 2009, cowwoc wrote: > > Sorry for all these emails but I keep on running into more issues. > Here is what I noticed: > > - CommPortIdentifier.getPortIdentifier("COM5") returns a > CommPortIdentifier where getName() == "COM5" > - If, however, you invoke CommPortIdentifier.open() you get back a > SerialPort where SerialPort.getName() is "//./COM5" > > I am expecting the name to remain consistent. "//./COM5" looks like > an implementation detail and (as far as I can tell) it can't be used as > an argument for any API method so it is somewhat useless. If getName() > were to return "COM5" I could at least use it to get back the original > CommPortIdentifier or compare against "known names" such as "COMx" or > "LPTx". What do you think? > Sure. If it itches enough you should be able to fix this in RXTXCommDriver.java. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Apr 5 10:27:58 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Apr 2009 10:27:58 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D8413D.7040105@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> Message-ID: On Sun, 5 Apr 2009, cowwoc wrote: > > I can reproduce a crash in RXTX 2.2 pre2 100% of the time using my > application code, but I can't seem to bring it down to a minimal testcase. > Here is what I see: > > - thread begins running > - open com1 > - close com1 > - open com5 > - leave com5 open > - thread shuts down > - repeat the same process in a new thread > - crash occurs when trying to open com1. Crash disappears if I close() com5 > in the previous thread. > > The output window contains the following: > > # > # A fatal error has been detected by the Java Runtime Environment: > # > # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x05475cf6, pid=6064, > tid=5436 > # > # JRE version: 6.0_14-b04 > # Java VM: Java HotSpot(TM) Client VM (14.0-b13 mixed mode, sharing > windows-x86 ) > # Problematic frame: > # C [rxtxSerial.dll+0x5cf6] > # > # An error report file with more information is saved as: > # C:\Users\Gili\Documents\foobar\source\hs_err_pid6064.log > # > # If you would like to submit a bug report, please visit: > # http://java.sun.com/webapps/bugreport/crash.jsp > Error 0x5 at ..\src\termios.c(892): Access is denied. > > > # The crash happened outside the Java Virtual Machine in native code. > # See problematic frame for where to report the bug. > # > > Please let me know if the crash dump is enough to track down this bug. > Hi Gili, You are responsible for cleaning up the serial ports when using threads. That said, if the thread did shut down, finalize should have been called if you are not passing the object around. See RXTXPort.java. protected void finalize() { if (debug) z.reportln( "RXTXPort:finalize()"); if( fd > 0 ) { if (debug) z.reportln( "RXTXPort:calling close()"); close(); } z.finalize(); } The exception is interesting. This is on Vista? Usually it just gives an open error when another process has the port. -- Trent Jarvi tjarvi at mathworks.com From cowwoc at bbs.darktech.org Sun Apr 5 10:35:55 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 12:35:55 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: References: <49D8413D.7040105@bbs.darktech.org> Message-ID: <49D8DDEB.5010908@bbs.darktech.org> Trent Jarvi wrote: > You are responsible for cleaning up the serial ports when using threads. > That said, if the thread did shut down, finalize should have been called > if you are not passing the object around. See RXTXPort.java. > > protected void finalize() > { > if (debug) > z.reportln( "RXTXPort:finalize()"); > if( fd > 0 ) > { > if (debug) > z.reportln( "RXTXPort:calling close()"); > close(); > } > z.finalize(); > } Two points: 1) One should never rely on finalizers because they may never run. 2) RXTX shouldn't cause the entire JVM to crash if I misuse the API. The native code should recover more gracefully. > The exception is interesting. This is on Vista? Usually it just gives > an open error when another process has the port. Yes, this is on Vista 64-bit. I'd really like to see this bug fixed. Is this code compilable under Visual Studio? If so, I can debug the problem on my end and send you a patch. Thanks, Gili From cowwoc at bbs.darktech.org Sun Apr 5 10:36:20 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 12:36:20 -0400 Subject: [Rxtx] SerialPort.getName() is wrong In-Reply-To: References: <49D84E93.7050606@bbs.darktech.org> Message-ID: <49D8DE04.6030306@bbs.darktech.org> Trent Jarvi wrote: >> I am expecting the name to remain consistent. "//./COM5" looks like >> an implementation detail and (as far as I can tell) it can't be used as >> an argument for any API method so it is somewhat useless. If getName() >> were to return "COM5" I could at least use it to get back the original >> CommPortIdentifier or compare against "known names" such as "COMx" or >> "LPTx". What do you think? >> > > Sure. > > If it itches enough you should be able to fix this in RXTXCommDriver.java. I'm not sure I understand. Are you saying that if I submit a patch you will commit it? Gili From tjarvi at qbang.org Sun Apr 5 10:46:23 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Apr 2009 10:46:23 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D8DDEB.5010908@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> Message-ID: On Sun, 5 Apr 2009, cowwoc wrote: > Trent Jarvi wrote: >> You are responsible for cleaning up the serial ports when using threads. >> That said, if the thread did shut down, finalize should have been called if >> you are not passing the object around. See RXTXPort.java. >> >> protected void finalize() >> { >> if (debug) >> z.reportln( "RXTXPort:finalize()"); >> if( fd > 0 ) >> { >> if (debug) >> z.reportln( "RXTXPort:calling close()"); >> close(); >> } >> z.finalize(); >> } > > Two points: > > 1) One should never rely on finalizers because they may never run. > 2) RXTX shouldn't cause the entire JVM to crash if I misuse the API. The > native code should recover more gracefully. > >> The exception is interesting. This is on Vista? Usually it just gives an >> open error when another process has the port. > > Yes, this is on Vista 64-bit. I'd really like to see this bug fixed. > Is this code compilable under Visual Studio? If so, I can debug the problem > on my end and send you a patch. > It will compile with the msvc cl.exe and nmake. See Makefile.msvc in the top level directory. You will need to adjust the JAVA_HOME variable. Also use the MSVC command prompt for x86_64 so cl and nmake are on your path. All the best, -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Apr 5 10:49:10 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Apr 2009 10:49:10 -0600 (MDT) Subject: [Rxtx] SerialPort.getName() is wrong In-Reply-To: <49D8DE04.6030306@bbs.darktech.org> References: <49D84E93.7050606@bbs.darktech.org> <49D8DE04.6030306@bbs.darktech.org> Message-ID: On Sun, 5 Apr 2009, cowwoc wrote: > Trent Jarvi wrote: >>> I am expecting the name to remain consistent. "//./COM5" looks like >>> an implementation detail and (as far as I can tell) it can't be used as >>> an argument for any API method so it is somewhat useless. If getName() >>> were to return "COM5" I could at least use it to get back the original >>> CommPortIdentifier or compare against "known names" such as "COMx" or >>> "LPTx". What do you think? >>> >> >> Sure. >> >> If it itches enough you should be able to fix this in RXTXCommDriver.java. > > I'm not sure I understand. Are you saying that if I submit a patch > you will commit it? > Hi Gili, Post a patch here and if nobody complains, we will commit it and give you credit. Yep. Other issues like changing the API to use java5 that may break existing apps are likely to run into objections but bug fixes usually get fixed just as you mention. -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Sun Apr 5 10:55:07 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 12:55:07 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> Message-ID: <49D8E26B.2040705@bbs.darktech.org> Trent Jarvi wrote: > It will compile with the msvc cl.exe and nmake. See Makefile.msvc in > the top level directory. You will need to adjust the JAVA_HOME > variable. Also use the MSVC command prompt for x86_64 so cl and nmake > are on your path. This is very odd. The CVS version of the code does not contain this file. Do you keep the latest code somewhere else? Gili From cowwoc at bbs.darktech.org Sun Apr 5 11:01:58 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 13:01:58 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D8E26B.2040705@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> Message-ID: <49D8E406.10708@bbs.darktech.org> cowwoc wrote: > Trent Jarvi wrote: >> It will compile with the msvc cl.exe and nmake. See Makefile.msvc in >> the top level directory. You will need to adjust the JAVA_HOME >> variable. Also use the MSVC command prompt for x86_64 so cl and nmake >> are on your path. > > This is very odd. The CVS version of the code does not contain this > file. Do you keep the latest code somewhere else? Okay I figured it out. CVS head is out of date, the "commapi-0-0-1" revision contains the correct files. Gili From tjarvi at qbang.org Sun Apr 5 11:05:43 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Apr 2009 11:05:43 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D8E26B.2040705@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> Message-ID: CVS HEAD is currently the rxtx 2.0 code. A branch was created long ago for 'experimental' gnu.io work. It just happens that the branch is what everyone uses now. checkout -r commapi-0-0-1 rxtx-devel will get the branch On Sun, 5 Apr 2009, cowwoc wrote: > Trent Jarvi wrote: >> It will compile with the msvc cl.exe and nmake. See Makefile.msvc in the >> top level directory. You will need to adjust the JAVA_HOME variable. Also >> use the MSVC command prompt for x86_64 so cl and nmake are on your path. > > This is very odd. The CVS version of the code does not contain this > file. Do you keep the latest code somewhere else? > > Gili > From cowwoc at bbs.darktech.org Sun Apr 5 14:50:47 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 16:50:47 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> Message-ID: <49D919A7.1070806@bbs.darktech.org> Okay, I tracked down the crash. It's being caused by YACK() using a 80-character buffer. The error message is longer than 80 characters, so _snprintf_s() crashes to avoid a buffer overflow. Please apply the attached patch and add the zipped up Visual Studio project directory. It's not perfect yet but it's a good start. Gili Trent Jarvi wrote: > > CVS HEAD is currently the rxtx 2.0 code. A branch was created long > ago for 'experimental' gnu.io work. It just happens that the branch > is what everyone uses now. > > checkout -r commapi-0-0-1 rxtx-devel > > will get the branch > > On Sun, 5 Apr 2009, cowwoc wrote: > >> Trent Jarvi wrote: >>> It will compile with the msvc cl.exe and nmake. See Makefile.msvc >>> in the top level directory. You will need to adjust the JAVA_HOME >>> variable. Also use the MSVC command prompt for x86_64 so cl and >>> nmake are on your path. >> >> This is very odd. The CVS version of the code does not contain >> this file. Do you keep the latest code somewhere else? >> >> Gili >> -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx-devel.patch Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20090405/d9b82962/attachment.pl -------------- next part -------------- A non-text attachment was scrubbed... Name: Win32.zip Type: application/octet-stream Size: 17764 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20090405/d9b82962/attachment-0002.obj From cowwoc at bbs.darktech.org Sun Apr 5 15:22:01 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 17:22:01 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D919A7.1070806@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> <49D919A7.1070806@bbs.darktech.org> Message-ID: <49D920F9.6080702@bbs.darktech.org> My mistake. The problem in YACK is real, but it isn't the real cause of the crash. The crash is caused by termios.c line 1099: index->prev->next = port; because in my case "index->prev==0". I think the bug is that the code assumes that index will contain a minimum of two entries if we're inserting a previously closed fd. In my case, it only contains one. I'm not sure why you have this code branch (as opposed to appending to the end of index). Please take a look. Thanks, Gili cowwoc wrote: > > Okay, I tracked down the crash. It's being caused by YACK() using a > 80-character buffer. The error message is longer than 80 characters, so > _snprintf_s() crashes to avoid a buffer overflow. > > Please apply the attached patch and add the zipped up Visual Studio > project directory. It's not perfect yet but it's a good start. > > Gili > > Trent Jarvi wrote: >> >> CVS HEAD is currently the rxtx 2.0 code. A branch was created long >> ago for 'experimental' gnu.io work. It just happens that the branch >> is what everyone uses now. >> >> checkout -r commapi-0-0-1 rxtx-devel >> >> will get the branch >> >> On Sun, 5 Apr 2009, cowwoc wrote: >> >>> Trent Jarvi wrote: >>>> It will compile with the msvc cl.exe and nmake. See Makefile.msvc >>>> in the top level directory. You will need to adjust the JAVA_HOME >>>> variable. Also use the MSVC command prompt for x86_64 so cl and >>>> nmake are on your path. >>> >>> This is very odd. The CVS version of the code does not contain >>> this file. Do you keep the latest code somewhere else? >>> >>> Gili >>> From tjarvi at qbang.org Sun Apr 5 16:13:27 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Apr 2009 16:13:27 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D920F9.6080702@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> <49D919A7.1070806@bbs.darktech.org> <49D920F9.6080702@bbs.darktech.org> Message-ID: Hi Gili, Are you using the cvs version? I thought we fixed the linked list issues. A solution was posted to the list. Let me look at work tomorrow to see what I have. On Sun, 5 Apr 2009, cowwoc wrote: > > My mistake. The problem in YACK is real, but it isn't the real cause > of the crash. The crash is caused by termios.c line 1099: > > index->prev->next = port; > > because in my case "index->prev==0". I think the bug is that the code > assumes that index will contain a minimum of two entries if we're inserting a > previously closed fd. In my case, it only contains one. > > I'm not sure why you have this code branch (as opposed to appending > to the end of index). Please take a look. > > Thanks, > Gili > > cowwoc wrote: >> >> Okay, I tracked down the crash. It's being caused by YACK() using a >> 80-character buffer. The error message is longer than 80 characters, so >> _snprintf_s() crashes to avoid a buffer overflow. >> >> Please apply the attached patch and add the zipped up Visual Studio >> project directory. It's not perfect yet but it's a good start. >> >> Gili >> >> Trent Jarvi wrote: >>> >>> CVS HEAD is currently the rxtx 2.0 code. A branch was created long ago >>> for 'experimental' gnu.io work. It just happens that the branch is what >>> everyone uses now. >>> >>> checkout -r commapi-0-0-1 rxtx-devel >>> >>> will get the branch >>> >>> On Sun, 5 Apr 2009, cowwoc wrote: >>> >>>> Trent Jarvi wrote: >>>>> It will compile with the msvc cl.exe and nmake. See Makefile.msvc in >>>>> the top level directory. You will need to adjust the JAVA_HOME >>>>> variable. Also use the MSVC command prompt for x86_64 so cl and nmake >>>>> are on your path. >>>> >>>> This is very odd. The CVS version of the code does not contain this >>>> file. Do you keep the latest code somewhere else? >>>> >>>> Gili >>>> > From ilkka at myller.com Sun Apr 5 23:58:08 2009 From: ilkka at myller.com (Ilkka Myller) Date: Mon, 6 Apr 2009 08:58:08 +0300 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> <49D919A7.1070806@bbs.darktech.org> <49D920F9.6080702@bbs.darktech.org> Message-ID: <19779C97-E0C7-4E3D-B715-F84F50F00CE6@myller.com> Hi all, I've already submitted the patch to fix this issue in february: http://mailman.qbang.org/pipermail/rxtx/2009-February/3989441.html The patch fixes the mentioned doubly linked list handling in termios.c -- I Trent Jarvi kirjoitti 6.4.2009 kello 1.13: > > Hi Gili, > > Are you using the cvs version? I thought we fixed the linked list > issues. > A solution was posted to the list. Let me look at work tomorrow to > see > what I have. > > > > On Sun, 5 Apr 2009, cowwoc wrote: > >> >> My mistake. The problem in YACK is real, but it isn't the real cause >> of the crash. The crash is caused by termios.c line 1099: >> >> index->prev->next = port; >> >> because in my case "index->prev==0". I think the bug is that the >> code >> assumes that index will contain a minimum of two entries if we're >> inserting a >> previously closed fd. In my case, it only contains one. >> >> I'm not sure why you have this code branch (as opposed to appending >> to the end of index). Please take a look. >> >> Thanks, >> Gili >> >> cowwoc wrote: >>> >>> Okay, I tracked down the crash. It's being caused by YACK() >>> using a >>> 80-character buffer. The error message is longer than 80 >>> characters, so >>> _snprintf_s() crashes to avoid a buffer overflow. >>> >>> Please apply the attached patch and add the zipped up Visual >>> Studio >>> project directory. It's not perfect yet but it's a good start. >>> >>> Gili >>> >>> Trent Jarvi wrote: >>>> >>>> CVS HEAD is currently the rxtx 2.0 code. A branch was created >>>> long ago >>>> for 'experimental' gnu.io work. It just happens that the branch >>>> is what >>>> everyone uses now. >>>> >>>> checkout -r commapi-0-0-1 rxtx-devel >>>> >>>> will get the branch >>>> >>>> On Sun, 5 Apr 2009, cowwoc wrote: >>>> >>>>> Trent Jarvi wrote: >>>>>> It will compile with the msvc cl.exe and nmake. See >>>>>> Makefile.msvc in >>>>>> the top level directory. You will need to adjust the JAVA_HOME >>>>>> variable. Also use the MSVC command prompt for x86_64 so cl and >>>>>> nmake >>>>>> are on your path. >>>>> >>>>> This is very odd. The CVS version of the code does not >>>>> contain this >>>>> file. Do you keep the latest code somewhere else? >>>>> >>>>> Gili >>>>> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Steffen.DETTMER at ingenico.com Mon Apr 6 02:53:47 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 6 Apr 2009 10:53:47 +0200 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D919A7.1070806@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> <49D919A7.1070806@bbs.darktech.org> Message-ID: <20090406085347.GM8289@elberon.bln.de.ingenico.com> Hi, just two minor details, first about the errno change, I though #include extern int errno; is correct (POSIX.1) - why this change? second about the log message, I think the maximum length could be limited and the return value of malloc must be checked for != NULL before using. Should it be _snprintf_s( message, 80, _TRUNCATE, "Error 0x%x at %s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); (I know that MS-CRT _snprintf does not guarantee to have a final EOS, but I think _snprintf_s with _TRUNCATE does so?). If it is known that truncation may happen maybe sizeof[message] could be increased; maybe using some %.20s could be used avoiding __FILE__ including big pathes to a message where all the message had been cut-off. To have it portable I think it could be: /* generally: */ #if defined(_MSC_VER) # define snprintf _snprintf #endif snprintf(message, sizeof(message), "Error 0x%x at %.20s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); message[sizeof(message)-1] = '\0'; /* needed for MS CRT snprintf */ (for length and size parameter I think size_t could be an option, but on several platforms, including MS-CRT and older glibc, there is no %z, unfortunately) oki, Steffen * cowwoc wrote on Sun, Apr 05, 2009 at 16:50 -0400: > > Okay, I tracked down the crash. It's being caused by YACK() using a > 80-character buffer. The error message is longer than 80 characters, so > _snprintf_s() crashes to avoid a buffer overflow. > > Please apply the attached patch and add the zipped up Visual Studio > project directory. It's not perfect yet but it's a good start. > > Gili > > Trent Jarvi wrote: > > > >CVS HEAD is currently the rxtx 2.0 code. A branch was created long > >ago for 'experimental' gnu.io work. It just happens that the branch > >is what everyone uses now. > > > >checkout -r commapi-0-0-1 rxtx-devel > > > >will get the branch > > > >On Sun, 5 Apr 2009, cowwoc wrote: > > > >>Trent Jarvi wrote: > >>>It will compile with the msvc cl.exe and nmake. See Makefile.msvc > >>>in the top level directory. You will need to adjust the JAVA_HOME > >>>variable. Also use the MSVC command prompt for x86_64 so cl and > >>>nmake are on your path. > >> > >> This is very odd. The CVS version of the code does not contain > >>this file. Do you keep the latest code somewhere else? > >> > >>Gili > >> > Index: ParallelImp.c > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/ParallelImp.c,v > retrieving revision 1.15.2.36 > diff -u -r1.15.2.36 ParallelImp.c > --- ParallelImp.c 11 Feb 2009 01:04:19 -0000 1.15.2.36 > +++ ParallelImp.c 5 Apr 2009 17:55:23 -0000 > @@ -119,7 +119,7 @@ > # include > #endif > > -extern int errno; > +_CRTIMP extern int * __cdecl _errno(void); > > #include "ParallelImp.h" > > @@ -181,8 +181,6 @@ > > #if defined (WIN32) > > -#define CTL_CODE( DeviceType, Function, Method, Access ) (((DeviceType) << 16) | ((Access) << 14) | ((Function) << 2) | (Method)) > - > #define FILE_DEVICE_PARALLEL_PORT 0x00000016 > #define METHOD_BUFFERED 0 > #define FILE_ANY_ACCESS 0 > @@ -253,7 +251,6 @@ > jobject jobj) > { > int fd = get_java_var( env, jobj,"fd","I" ); > - int status; > #if defined (__linux__) > ioctl(fd, LPGETSTATUS, &status); > #elif defined (WIN32) > Index: SerialImp.c > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v > retrieving revision 1.46.2.203 > diff -u -r1.46.2.203 SerialImp.c > --- SerialImp.c 19 Mar 2009 03:27:48 -0000 1.46.2.203 > +++ SerialImp.c 5 Apr 2009 17:49:48 -0000 > @@ -147,7 +147,7 @@ > #include > #endif /* LIBLOCKDEV */ > > -extern int errno; > +_CRTIMP extern int * __cdecl _errno(void); > > #include "SerialImp.h" > > Index: termios.c > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/termios.c,v > retrieving revision 1.9.2.62 > diff -u -r1.9.2.62 termios.c > --- termios.c 13 Jan 2009 03:08:55 -0000 1.9.2.62 > +++ termios.c 5 Apr 2009 17:54:09 -0000 > @@ -88,7 +88,7 @@ > #define SIGIO 0 > > int my_errno; > -extern int errno; > +_CRTIMP extern int * __cdecl _errno(void); > struct termios_list > { > char filename[80]; > @@ -1350,7 +1350,7 @@ > In that case use EAGAIN. See SerialImp.c:testRead() > ----------------------------------------------------------*/ > > -int serial_read( int fd, void *vb, int size ) > +int serial_read( int fd, void *vb, unsigned int size ) > { > long start, now; > unsigned long nBytes = 0, total = 0, error; > Index: win32termios.h > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/win32termios.h,v > retrieving revision 1.5.2.34 > diff -u -r1.5.2.34 win32termios.h > --- win32termios.h 5 Feb 2009 01:25:05 -0000 1.5.2.34 > +++ win32termios.h 5 Apr 2009 20:29:30 -0000 > @@ -60,6 +60,7 @@ > #include > #include > #include > +#include > #ifdef TRACE > #define ENTER(x) report("entering "x" \n"); > #define LEAVE(x) report("leaving "x" \n"); > @@ -70,8 +71,9 @@ > #if defined(_MSC_VER) > #define YACK() \ > { \ > - char *allocTextBuf, message[80]; \ > - unsigned long nChars; \ > + char *allocTextBuf, *message; \ > + const unsigned short longestNumber = 20; \ > + unsigned long nChars, len; \ > unsigned int errorCode = GetLastError(); \ > nChars = FormatMessage ( \ > FORMAT_MESSAGE_ALLOCATE_BUFFER | \ > @@ -82,8 +84,12 @@ > (LPSTR)&allocTextBuf, \ > 16, \ > NULL ); \ > - _snprintf_s( message, 80, 80, "Error 0x%x at %s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); \ > + len = strlen("Error 0x") + longestNumber + strlen(" at ") + strlen(__FILE__) + longestNumber + \ > + strlen(": ") + ((nChars+1) * sizeof(TCHAR)) + 1; \ > + message = malloc(len); \ > + _snprintf_s( message, len, len - 1, "Error 0x%x at %s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); \ > report_error( message ); \ > + free(message); \ > LocalFree(allocTextBuf); \ > Sleep(1); \ > } > @@ -173,7 +179,7 @@ > int serial_test( char * ); > int serial_open(const char *File, int flags, ... ); > int serial_close(int fd); > -int serial_read(int fd, void *b, int size); > +int serial_read(int fd, void *b, unsigned int size); > int serial_write(int fd, char *Str, int length); > /* > * lcc winsock.h conflicts > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx End of message. ------------------------------------------------------------------->8======= About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From bill7007 at gmail.com Mon Apr 6 16:34:50 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Mon, 6 Apr 2009 18:34:50 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: <49D693BA.8060909@gatworks.com> References: <49D546F8.20807@gatworks.com> <49D693BA.8060909@gatworks.com> Message-ID: Once it hung, three stack dumps minutes apart were exactly the same. I have a noticed that when it hangs, the read appears after flush() enter and before flush leave() that doesn't happen like: RXTXPort:SerialOutputStream:flush() enter RXTXPort:SerialInputStream:read(8192 0 8192) called When it works, flush() enter and leave happen together. It may just be because flush() hangs and read is the only other thread waiting to run at that point. I don't know much about the RXTX design and kernel interaction, just digging through the code some. Is there a design description somewhere? Am hung up on target system compile since UTS_RELEASE seems no longer defined for 2.6.18 up kernels and have not figured a good patch yet. But, that is another issue. Thanks for the good help. On Fri, Apr 3, 2009 at 6:54 PM, U. George wrote: > I would have tried 2 or 3 "^\" . If things are stuck, then all will be at > same 'java' instruction. If thread is moving, then one of the snapshots > would be different. > > I *think* flushing/draining wont return until the kernel buffers to device > have been accepted by device. Stuck/paused device? > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090406/c4b509d8/attachment.html From tjarvi at qbang.org Mon Apr 6 17:45:38 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 6 Apr 2009 17:45:38 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <20090406085347.GM8289@elberon.bln.de.ingenico.com> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> <49D919A7.1070806@bbs.darktech.org> <20090406085347.GM8289@elberon.bln.de.ingenico.com> Message-ID: The error bits in the patch can probably just be dropped out. I don't see what they solve. Your snprintf define appears to work. The following is what I'd like to put in if noone objects. #if defined(_MSC_VER) # define snprintf _snprintf #endif #define YACK() \ { \ char *allocTextBuf, message[80]; \ unsigned long nChars; \ unsigned int errorCode = GetLastError(); \ nChars = FormatMessage ( \ FORMAT_MESSAGE_ALLOCATE_BUFFER | \ FORMAT_MESSAGE_FROM_SYSTEM, \ NULL, \ errorCode, \ MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT), \ (LPSTR)&allocTextBuf, \ 16, \ NULL ); \ snprintf( message, 80, "Error 0x%x at %s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); \ message[sizeof(message)-1] = '\0'; /* needed for MS CRT snprintf */ \ report_error( message ); \ LocalFree(allocTextBuf); \ Sleep(1); \ } On Mon, 6 Apr 2009, Steffen DETTMER wrote: > Hi, > > just two minor details, first about the errno change, I though > > #include > extern int errno; > > is correct (POSIX.1) - why this change? > > second about the log message, I think the maximum length could be > limited and the return value of malloc must be checked for != > NULL before using. > > Should it be > > _snprintf_s( message, 80, _TRUNCATE, "Error 0x%x at %s(%d): %s\n", > errorCode, __FILE__, __LINE__, allocTextBuf); > > (I know that MS-CRT _snprintf does not guarantee to have a final > EOS, but I think _snprintf_s with _TRUNCATE does so?). > > If it is known that truncation may happen maybe sizeof[message] > could be increased; maybe using some %.20s could be used avoiding > __FILE__ including big pathes to a message where all the message > had been cut-off. > > To have it portable I think it could be: > > /* generally: */ > #if defined(_MSC_VER) > # define snprintf _snprintf > #endif > > snprintf(message, sizeof(message), "Error 0x%x at %.20s(%d): %s\n", > errorCode, __FILE__, __LINE__, allocTextBuf); > message[sizeof(message)-1] = '\0'; /* needed for MS CRT snprintf */ > > (for length and size parameter I think size_t could be an option, > but on several platforms, including MS-CRT and older glibc, > there is no %z, unfortunately) > > oki, > > Steffen > > > * cowwoc wrote on Sun, Apr 05, 2009 at 16:50 -0400: >> >> Okay, I tracked down the crash. It's being caused by YACK() using a >> 80-character buffer. The error message is longer than 80 characters, so >> _snprintf_s() crashes to avoid a buffer overflow. >> >> Please apply the attached patch and add the zipped up Visual Studio >> project directory. It's not perfect yet but it's a good start. >> >> Gili >> >> Trent Jarvi wrote: >> > >> >CVS HEAD is currently the rxtx 2.0 code. A branch was created long >> >ago for 'experimental' gnu.io work. It just happens that the branch >> >is what everyone uses now. >> > >> >checkout -r commapi-0-0-1 rxtx-devel >> > >> >will get the branch >> > >> >On Sun, 5 Apr 2009, cowwoc wrote: >> > >> >>Trent Jarvi wrote: >> >>>It will compile with the msvc cl.exe and nmake. See Makefile.msvc >> >>>in the top level directory. You will need to adjust the JAVA_HOME >> >>>variable. Also use the MSVC command prompt for x86_64 so cl and >> >>>nmake are on your path. >> >> >> >> This is very odd. The CVS version of the code does not contain >> >>this file. Do you keep the latest code somewhere else? >> >> >> >>Gili >> >> > >> Index: ParallelImp.c >> =================================================================== >> RCS file: /usr/local/cvsroot/rxtx-devel/src/ParallelImp.c,v >> retrieving revision 1.15.2.36 >> diff -u -r1.15.2.36 ParallelImp.c >> --- ParallelImp.c 11 Feb 2009 01:04:19 -0000 1.15.2.36 >> +++ ParallelImp.c 5 Apr 2009 17:55:23 -0000 >> @@ -119,7 +119,7 @@ >> # include >> #endif >> >> -extern int errno; >> +_CRTIMP extern int * __cdecl _errno(void); >> >> #include "ParallelImp.h" >> >> @@ -181,8 +181,6 @@ >> >> #if defined (WIN32) >> >> -#define CTL_CODE( DeviceType, Function, Method, Access ) (((DeviceType) << 16) | ((Access) << 14) | ((Function) << 2) | (Method)) >> - >> #define FILE_DEVICE_PARALLEL_PORT 0x00000016 >> #define METHOD_BUFFERED 0 >> #define FILE_ANY_ACCESS 0 >> @@ -253,7 +251,6 @@ >> jobject jobj) >> { >> int fd = get_java_var( env, jobj,"fd","I" ); >> - int status; >> #if defined (__linux__) >> ioctl(fd, LPGETSTATUS, &status); >> #elif defined (WIN32) >> Index: SerialImp.c >> =================================================================== >> RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v >> retrieving revision 1.46.2.203 >> diff -u -r1.46.2.203 SerialImp.c >> --- SerialImp.c 19 Mar 2009 03:27:48 -0000 1.46.2.203 >> +++ SerialImp.c 5 Apr 2009 17:49:48 -0000 >> @@ -147,7 +147,7 @@ >> #include >> #endif /* LIBLOCKDEV */ >> >> -extern int errno; >> +_CRTIMP extern int * __cdecl _errno(void); >> >> #include "SerialImp.h" >> >> Index: termios.c >> =================================================================== >> RCS file: /usr/local/cvsroot/rxtx-devel/src/termios.c,v >> retrieving revision 1.9.2.62 >> diff -u -r1.9.2.62 termios.c >> --- termios.c 13 Jan 2009 03:08:55 -0000 1.9.2.62 >> +++ termios.c 5 Apr 2009 17:54:09 -0000 >> @@ -88,7 +88,7 @@ >> #define SIGIO 0 >> >> int my_errno; >> -extern int errno; >> +_CRTIMP extern int * __cdecl _errno(void); >> struct termios_list >> { >> char filename[80]; >> @@ -1350,7 +1350,7 @@ >> In that case use EAGAIN. See SerialImp.c:testRead() >> ----------------------------------------------------------*/ >> >> -int serial_read( int fd, void *vb, int size ) >> +int serial_read( int fd, void *vb, unsigned int size ) >> { >> long start, now; >> unsigned long nBytes = 0, total = 0, error; >> Index: win32termios.h >> =================================================================== >> RCS file: /usr/local/cvsroot/rxtx-devel/src/win32termios.h,v >> retrieving revision 1.5.2.34 >> diff -u -r1.5.2.34 win32termios.h >> --- win32termios.h 5 Feb 2009 01:25:05 -0000 1.5.2.34 >> +++ win32termios.h 5 Apr 2009 20:29:30 -0000 >> @@ -60,6 +60,7 @@ >> #include >> #include >> #include >> +#include >> #ifdef TRACE >> #define ENTER(x) report("entering "x" \n"); >> #define LEAVE(x) report("leaving "x" \n"); >> @@ -70,8 +71,9 @@ >> #if defined(_MSC_VER) >> #define YACK() \ >> { \ >> - char *allocTextBuf, message[80]; \ >> - unsigned long nChars; \ >> + char *allocTextBuf, *message; \ >> + const unsigned short longestNumber = 20; \ >> + unsigned long nChars, len; \ >> unsigned int errorCode = GetLastError(); \ >> nChars = FormatMessage ( \ >> FORMAT_MESSAGE_ALLOCATE_BUFFER | \ >> @@ -82,8 +84,12 @@ >> (LPSTR)&allocTextBuf, \ >> 16, \ >> NULL ); \ >> - _snprintf_s( message, 80, 80, "Error 0x%x at %s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); \ >> + len = strlen("Error 0x") + longestNumber + strlen(" at ") + strlen(__FILE__) + longestNumber + \ >> + strlen(": ") + ((nChars+1) * sizeof(TCHAR)) + 1; \ >> + message = malloc(len); \ >> + _snprintf_s( message, len, len - 1, "Error 0x%x at %s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); \ >> report_error( message ); \ >> + free(message); \ >> LocalFree(allocTextBuf); \ >> Sleep(1); \ >> } >> @@ -173,7 +179,7 @@ >> int serial_test( char * ); >> int serial_open(const char *File, int flags, ... ); >> int serial_close(int fd); >> -int serial_read(int fd, void *b, int size); >> +int serial_read(int fd, void *b, unsigned int size); >> int serial_write(int fd, char *Str, int length); >> /* >> * lcc winsock.h conflicts >> > > >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > > > > > > > > > > > > End of message. > ------------------------------------------------------------------->8======= > > > About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. > This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > P Please consider the environment before printing this e-mail > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Apr 6 18:11:28 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 6 Apr 2009 18:11:28 -0600 (MDT) Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: <49D546F8.20807@gatworks.com> <49D693BA.8060909@gatworks.com> Message-ID: UTS_RELEASE is defined in now. The check really should be removed from RXTX. It was a defensive check for wilder times when GNU glibc did not have defines the kernel headers had so rxtx would include the kernel headers instead. :/ If you don't have linux/version.h, it is generated when you configure the kernel. make oldconfig used to do the trick. It may make sense to work with the prerelease or CVS code. RXTX just assumes that flush, read and anything else the kernel exposes may be called at anytime from any thread. There isn't a design for the kernel interaction. There are higher level constraints put in Java to prevent some things happening at the same time with 'synchronized.' RXTXPort.java has all of those. When the port is opened, a native event thread is started which uses select to know if an event has happened. BSD like systems have a native thread that fires off on write which tries to flush() to determine when the output buffer is empty asynchronously. The rest is not marshaled in any fashion at the native level. T I think there is a lower level deadlock being triggered in flush as well. I don't think it should be possible if everything was right underneath us. You may want to examine the java code closer to make sure it isnt possible the lock is there. On Mon, 6 Apr 2009, Bill Johnson wrote: > Once it hung, three stack dumps minutes apart were exactly the same. > I have a noticed that when it hangs, the read appears after flush() enter and > before flush leave() that doesn't happen like: > RXTXPort:SerialOutputStream:flush() enter > RXTXPort:SerialInputStream:read(8192 0 8192) called > > When it works, flush() enter and leave happen together. It may just be because > flush() hangs and read is the only other thread waiting to run at that point. > I don't know much about the RXTX design and kernel interaction, just digging > through the code some. Is there a design description somewhere? > > Am hung up on target system compile since UTS_RELEASE seems no longer defined for > 2.6.18 up kernels and have not figured a good patch yet. But, that is another > issue. > > Thanks for the good help. > > > On Fri, Apr 3, 2009 at 6:54 PM, U. George wrote: > I would have tried 2 or 3 "^\" . If things are stuck, then all will be > at same 'java' instruction. If thread is moving, then one of the > snapshots would be different. > > I *think* flushing/draining wont return until the kernel buffers to > device have been accepted by device. Stuck/paused device? > > > > > From tjarvi at qbang.org Mon Apr 6 18:28:50 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 6 Apr 2009 18:28:50 -0600 (MDT) Subject: [Rxtx] CVS updates. Pre3 is comming. Message-ID: I need to go through the bugzilla reports prior to the pre3 release. I think this should be close if you want to check it out from CVS. added: YACK() debug overflow fix for windows Steffen DETTMER (and many others) multiport fix for windows. Ilkka Myller http://mailman.qbang.org/pipermail/rxtx/2009-February/3989441.html I think this code is current. If I missed something, yell. CVS Info: export/setenv CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login # passwd mousy cvs checkout -r commapi-0-0-1 rxtx-devel -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Apr 6 22:32:07 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 6 Apr 2009 22:32:07 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D919A7.1070806@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> <49D919A7.1070806@bbs.darktech.org> Message-ID: Ah. I'll put this in CVS tomorrow. I did sync up the code with my work sandbox today. I just forgot to pull and add this. On Sun, 5 Apr 2009, cowwoc wrote: > > Okay, I tracked down the crash. It's being caused by YACK() using a > 80-character buffer. The error message is longer than 80 characters, so > _snprintf_s() crashes to avoid a buffer overflow. > > Please apply the attached patch and add the zipped up Visual Studio > project directory. It's not perfect yet but it's a good start. > > Gili > > Trent Jarvi wrote: >> >> CVS HEAD is currently the rxtx 2.0 code. A branch was created long ago for >> 'experimental' gnu.io work. It just happens that the branch is what >> everyone uses now. >> >> checkout -r commapi-0-0-1 rxtx-devel >> >> will get the branch >> >> On Sun, 5 Apr 2009, cowwoc wrote: >> >>> Trent Jarvi wrote: >>>> It will compile with the msvc cl.exe and nmake. See Makefile.msvc in the >>>> top level directory. You will need to adjust the JAVA_HOME variable. >>>> Also use the MSVC command prompt for x86_64 so cl and nmake are on your >>>> path. >>> >>> This is very odd. The CVS version of the code does not contain this >>> file. Do you keep the latest code somewhere else? >>> >>> Gili >>> > From cowwoc at bbs.darktech.org Tue Apr 7 06:07:46 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Tue, 07 Apr 2009 08:07:46 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: References: Message-ID: <49DB4212.40807@bbs.darktech.org> > just two minor details, first about the errno change, I though > > #include > extern int errno; > > is correct (POSIX.1) - why this change? If you compile this under Visual Studio 2008 you will get warnings that the errno type being imported is different from the type being exported. The definition I pasted is the one being exported. Perhaps we should use #ifdef WIN32 for this? Gili From cowwoc at bbs.darktech.org Wed Apr 1 22:05:13 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Thu, 02 Apr 2009 00:05:13 -0400 Subject: [Rxtx] Windows 64-bit support? Message-ID: <49D43979.4050702@bbs.darktech.org> Hi, I'd like to run RXTX under the Windows 64-bit JVM. Are there plans to release an official 64-bit version anytime soon? Gili From bill7007 at gmail.com Thu Apr 2 16:01:17 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Thu, 2 Apr 2009 18:01:17 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel Message-ID: Hi, I have an rxtx serial application that used to work reliably until I had to move it to newer hardware and kernel. Now, the application sometimes hangs near first port use. When it does hang, it can be released by starting a second copy of the application which is locked out of the ports but does release the first process. Upgraded from rxtx-2.1-7-r2 to rxtx-2.2pre2 but still hangs. Tried to rebuild on the target machine and ran into the 'UTS_RELEASE' undeclared problem so holding on that approach. Recompiled OK on a 2.6.9-42.0.3.ELsmp system. Debug messages were turned on using: "./configure --enable-DEBUG" and modified RXTXPort.java with: "debug = true;" "z = new Zystem(Zystem.PRINT_MODE);" Below is capture of the application with debugging enabled. It show the application hang point, and the second application's printout at the release point. (pre3 is the locally modified version of pre2) Any suggestions on how to pin this down further? Thanks, +BillJ $ java -version java version "1.5.0_06" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05) Java HotSpot(TM) Client VM (build 1.5.0_06-b05, mixed mode, sharing) $ uname -a Linux qms4 2.6.18-92.1.6.el5 #1 SMP Wed Jun 25 13:49:24 EDT 2008 i686 i686 i386 GNU/Linux ***CAPTURE: [qms at qms4 ~]$ ./qms/ScriptFiles/startup.sh Thu Apr 02 13:35:45 EDT 2009:Setting Log File to:/home/qms/qms/QMS.log Thu Apr 02 13:35:45 EDT 2009:TSettings.HandleIni:ReUsing Ini file:/home/qms/qms/qms.properties WARNING: RXTX Version mismatch Jar version = RXTX-2.2pre2 native lib Version = RXTX-2.2pre3 fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB2 fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB1 fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB0 fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile RXTXPort {} RXTX WARNING: This library was compiled to run with OS release 2.4.20 and you are currently running OS release 2.6.18-92.1.6.el5. In some cases this can be a problem. Try recompiling RXTX if you notice strange behavior. If you just compiled RXTX make sure /usr/include/linux is a symbolic link to the include files that came with the kernel source and not an older copy. press enter to continue RXTXPort:RXTXPort(/dev/ttyUSB2) called fhs_lock: creating lockfile: 10127 open: locking worked for /dev/ttyUSB2 open: fd returned is 8 RXTXPort:MontitorThread:MonitorThread() RXTXPort:MontitorThread:run() has_line_status_register_acess: Port does not support TIOCSERGETLSR init_threads: get eis init_threads: set eis init_threads: stop RXTXPort:RXTXPort(/dev/ttyUSB2) returns with fd = 8 RXTXPort:setSerialPortParams(38400 8 1 0) called RXTXPort:setSerialPortParams(38400 8 1 0) returning RXTXPort:getInputStream() called and returning Thu Apr 02 13:36:02 EDT 2009:TSerial[22]:Using Port:/dev/ttyUSB2 RXTXPort:getOutputStream() called and returning Thu Apr 02 13:36:02 EDT 2009:TSerial[22].Transmit:TN Entering RXTXPort:SerialOutputStream:write(4) writeArray() Leaving RXTXPort:SerialOutputStream:write(4) RXTXPort:SerialOutputStream:flush() enter RXTXPort:SerialOutputStream:flush() leave Thu Apr 02 13:36:02 EDT 2009:TSerial[22].Transmit:RV Entering RXTXPort:SerialOutputStream:write(4) writeArray() Leaving RXTXPort:SerialOutputStream:write(4) RXTXPort:SerialOutputStream:flush() enter RXTXPort:SerialInputStream:read(8192 0 8192) called ***FIRST PROCESS HANGS HERE ***THEN PROCEEDS AFTER SECOND PROCESS STARTS RXTXPort:SerialOutputStream:flush() leave Thu Apr 02 13:41:29 EDT 2009:TSerial[22].Transmit:IH9 Entering RXTXPort:SerialOutputStream:write(5) writeArray() Leaving RXTXPort:SerialOutputStream:write(5) RXTXPort:SerialOutputStream:flush() enter RXTXPort:SerialOutputStream:flush() leave Thu Apr 02 13:41:29 EDT 2009:TSerial[22].Transmit:IL11 ***END CAPTURE ***CAPTURE SECOND PROCESS FAILS OPEN [qms at qms4 ~]$ ./qms/ScriptFiles/startup.sh Thu Apr 02 13:41:27 EDT 2009:Setting Log File to:/home/qms/qms/QMS.log Thu Apr 02 13:41:27 EDT 2009:TSettings.HandleIni:ReUsing Ini file:/home/qms/qms/qms.properties WARNING: RXTX Version mismatch Jar version = RXTX-2.2pre2 native lib Version = RXTX-2.2pre3 fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB2: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB1: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB0: File exists fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB2: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB1: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB0: File exists fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile Thu Apr 02 13:41:30 EDT 2009:TIOBoard: java.io.IOException: java.io.IOException: TSerial[22]: Open Failed ***END CAPTURE -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090402/c66f8d70/attachment-0006.html From netbeans at gatworks.com Thu Apr 2 17:15:04 2009 From: netbeans at gatworks.com (U. George) Date: Thu, 02 Apr 2009 19:15:04 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: Message-ID: <49D546F8.20807@gatworks.com> > "z = new Zystem(Zystem.PRINT_MODE);" > Below is capture of the application with debugging enabled. It show > the application hang point, and the second application's printout at the > release point. (pre3 is the locally modified version of pre2) > Any suggestions on how to pin this down further? > Thanks, > +BillJ When perceived runability is hung, try a ^\ ( control \) on console. This gets the JVM to dump the stacks of all the java threads. If you know the thread that is stuck, then u can see what java statement its stuck at. From tjarvi at qbang.org Thu Apr 2 19:25:17 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 2 Apr 2009 19:25:17 -0600 (MDT) Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: <49D546F8.20807@gatworks.com> References: <49D546F8.20807@gatworks.com> Message-ID: On Thu, 2 Apr 2009, U. George wrote: >> "z = new Zystem(Zystem.PRINT_MODE);" >> Below is capture of the application with debugging enabled. It show >> the application hang point, and the second application's printout at the >> release point. (pre3 is the locally modified version of pre2) >> Any suggestions on how to pin this down further? >> Thanks, >> +BillJ > > When perceived runability is hung, try a ^\ ( control \) on console. > This gets the JVM to dump the stacks of all the java threads. > If you know the thread that is stuck, then u can see what java statement > its stuck at. I've also noticed some linux systems hanging with open/read/write and saw kacpid storms. I need to look at it more but did observe kacpid consuming a core and not returning to a normal state for a significant period of time. It was easy to observe from top sorted by CPU usage. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Apr 2 19:26:18 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 2 Apr 2009 19:26:18 -0600 (MDT) Subject: [Rxtx] Windows 64-bit support? In-Reply-To: <49D43979.4050702@bbs.darktech.org> References: <49D43979.4050702@bbs.darktech.org> Message-ID: On Thu, 2 Apr 2009, cowwoc wrote: > Hi, > > I'd like to run RXTX under the Windows 64-bit JVM. Are there plans > to release an official 64-bit version anytime soon? > It is in the prerelease and will be in the final release. I'm pushing it through as fast as I can in my free time. -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Thu Apr 2 22:57:34 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Fri, 03 Apr 2009 00:57:34 -0400 Subject: [Rxtx] Missing documentation In-Reply-To: References: <49D43979.4050702@bbs.darktech.org> Message-ID: <49D5973E.4050400@bbs.darktech.org> Hi, I noticed that RXTX 2.1 drops javax.comm support in favor of gnu.io. I have one major problem with this: the gui.io.* documentation is very poor. Many classes and methods have no Javadoc at all which makes them difficult to use. Please fix this for the final release. Thank you, Gili From alex.sas at freemail.hu Fri Apr 3 01:36:54 2009 From: alex.sas at freemail.hu (Sas Alex) Date: Fri, 3 Apr 2009 09:36:54 +0200 (CEST) Subject: [Rxtx] Serial port false reads Message-ID: Hi all, On Windows XP, using rxtx-2.1-7-r2 I have a program communicating on a serial line like the following (excerpt): { os.write(command); os.flush(); // Thread.sleep(period); // read response while(is.available() > 0) { is.read() } } If there is a sleep between the os.flush and the reading cycle the correct answer is received. Otherwise (sometimes) there are extra, erronous characters at the beginning of the answer, but the correct answer (according to the protocol) also arrives, afterwards. Is this a normal behaviour, one should wait before the read? If yes, is there a way to determine the minimum amount of time to wait for? Serial port params are: 9600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE. Thank you in advance, Alex ________________________________________________________ El?foglal?si akci? meghosszabb?tva! Korfui ?d?l?s m?r 56.910 Ft-t?l. http://www.budavartours.hu/gorogorszag/?utm_campaign=origo&utm_source=freemail_kimeno_090403&utm_medium=ct&utm_content=korfu_elofoglalasi_akcio#reg_Korfu -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090403/8f3650ea/attachment-0006.html From bill7007 at gmail.com Fri Apr 3 16:15:30 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Fri, 3 Apr 2009 18:15:30 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: <49D546F8.20807@gatworks.com> Message-ID: > When perceived runability is hung, try a ^\ ( control \) on console. >> This gets the JVM to dump the stacks of all the java threads. > > Good idea... A thread dump is below, it looks like only some system threads are in wait state which is probably normal. The "main" thread is stopped writing the first data out the serial port which should complete but its has stopped at: at gnu.io.RXTXPort.nativeDrain(Native Method) It show its state as runnable though. There is another thread, "SerialReader_22", that is waiting to read any data on the same port. I'll bring the app up under Netbeans debugger next. >> > I've also noticed some linux systems hanging with open/read/write and saw > kacpid storms. No CPU use going when it hangs, acts like a deadlock. THREAD DUMP AT HANG: Entering RXTXPort:SerialOutputStream:write(4) writeArray() Leaving RXTXPort:SerialOutputStream:write(4) RXTXPort:SerialOutputStream:flush() enter RXTXPort:SerialInputStream:read(8192 0 8192) called Full thread dump Java HotSpot(TM) Client VM (1.5.0_06-b05 mixed mode, sharing): "SerialReader_22" daemon prio=1 tid=0x087abf38 nid=0x3c8b runnable [0xb1a43000..0xb1a43f30] at gnu.io.RXTXPort.readArray(Native Method) at gnu.io.RXTXPort$SerialInputStream.read(RXTXPort.java:1454) - locked <0x88ca55b8> (a gnu.io.RXTXPort$SerialInputStream) at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:411) at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) - locked <0x88cab378> (a java.io.InputStreamReader) at java.io.InputStreamReader.read(InputStreamReader.java:167) at java.io.BufferedReader.fill(BufferedReader.java:136) at java.io.BufferedReader.readLine(BufferedReader.java:299) - locked <0x88cab378> (a java.io.InputStreamReader) at java.io.BufferedReader.readLine(BufferedReader.java:362) at qms.TSerialPort$SerialRead.run(TSerialPort.java:268) at java.lang.Thread.run(Thread.java:595) "Thread-1" prio=1 tid=0x08a43360 nid=0x3c8a runnable [0xb1ac4000..0xb1ac4db0] at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1641) "AWT-XAWT" daemon prio=1 tid=0x08acc848 nid=0x3c87 runnable [0xb1b45000..0xb1b45e30] at sun.awt.X11.XToolkit.waitForEvents(Native Method) at sun.awt.X11.XToolkit.run(XToolkit.java:463) at sun.awt.X11.XToolkit.run(XToolkit.java:438) at java.lang.Thread.run(Thread.java:595) "Java2D Disposer" daemon prio=1 tid=0x08ab9d30 nid=0x3c86 in Object.wait() [0xb1bc6000..0xb1bc70b0] at java.lang.Object.wait(Native Method) - waiting on <0x8917b110> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:116) - locked <0x8917b110> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:132) at sun.java2d.Disposer.run(Disposer.java:107) at java.lang.Thread.run(Thread.java:595) "Low Memory Detector" daemon prio=1 tid=0x087bea68 nid=0x3c84 runnable [0x00000000..0x00000000] "CompilerThread0" daemon prio=1 tid=0x087bd4c0 nid=0x3c83 waiting on condition [0x00000000..0xb23a7a18] "Signal Dispatcher" daemon prio=1 tid=0x087bc520 nid=0x3c82 runnable [0x00000000..0x00000000] "Finalizer" daemon prio=1 tid=0x087b5710 nid=0x3c81 in Object.wait() [0xb26a9000..0xb26a9f30] at java.lang.Object.wait(Native Method) - waiting on <0x8914a770> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:116) - locked <0x8914a770> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:132) at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159) "Reference Handler" daemon prio=1 tid=0x087b49c8 nid=0x3c80 in Object.wait() [0xb272a000..0xb272adb0] at java.lang.Object.wait(Native Method) - waiting on <0x8914a7f0> (a java.lang.ref.Reference$Lock) at java.lang.Object.wait(Object.java:474) at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116) - locked <0x8914a7f0> (a java.lang.ref.Reference$Lock) "main" prio=1 tid=0x08777b88 nid=0x3c7e runnable [0xbffa7000..0xbffa74f8] at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1248) at qms.TSerialPort.Transmit(TSerialPort.java:192) - locked <0x88c99a68> (a qms.TSerialPort) at qms.TIOBoard.GetIOBoardVersion(TIOBoard.java:168) at qms.TIOBoard.(TIOBoard.java:73) at qms.TQMS.(TQMS.java:47) at qms.MainForm.(MainForm.java:2076) at qms.MainForm.main(MainForm.java:2099) "VM Thread" prio=1 tid=0x087b1e20 nid=0x3c7f runnable "VM Periodic Task Thread" prio=1 tid=0x087bff50 nid=0x3c85 waiting on condition -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090403/20b7bca4/attachment-0005.html From Martin.Oberhuber at windriver.com Fri Apr 3 16:23:43 2009 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Sat, 4 Apr 2009 00:23:43 +0200 Subject: [Rxtx] Missing documentation In-Reply-To: <49D5973E.4050400@bbs.darktech.org> References: <49D43979.4050702@bbs.darktech.org> <49D5973E.4050400@bbs.darktech.org> Message-ID: <460801A4097E3D4CA04CC64EE648584809C8BD6F@ism-mail03.corp.ad.wrs.com> Hello Gili, The classes in the gnu.io namespace are designed to work exactly as their counterparts in the javax.comm namespace. Therefore, if you just take the javax.comm Javadocs that's what you want. Unfortunately I don't think we can just copy & paste the javax.comm Javadocs into RXTX due to license restrictions. I guess that's the main reason why RXTX is not (yet) Javadoc'd as extensively as it should be. Actually, writing Javadocs from scratch WITHOUT referencing the wording of the Sun Javadocs is not that easy. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of cowwoc > Sent: Freitag, 03. April 2009 06:58 > To: rxtx at qbang.org > Subject: [Rxtx] Missing documentation > > Hi, > > I noticed that RXTX 2.1 drops javax.comm support in favor > of gnu.io. > I have one major problem with this: the gui.io.* > documentation is very > poor. Many classes and methods have no Javadoc at all which > makes them > difficult to use. Please fix this for the final release. > > Thank you, > Gili > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Fri Apr 3 16:54:50 2009 From: netbeans at gatworks.com (U. George) Date: Fri, 03 Apr 2009 18:54:50 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: <49D546F8.20807@gatworks.com> Message-ID: <49D693BA.8060909@gatworks.com> I would have tried 2 or 3 "^\" . If things are stuck, then all will be at same 'java' instruction. If thread is moving, then one of the snapshots would be different. I *think* flushing/draining wont return until the kernel buffers to device have been accepted by device. Stuck/paused device? Bill Johnson wrote: > > > > > When perceived runability is hung, try a ^\ ( control \) on console. > This gets the JVM to dump the stacks of all the java threads. > > > Good idea... A thread dump is below, it looks like only some system > threads are in wait state which is prob From cowwoc at bbs.darktech.org Fri Apr 3 17:45:09 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Fri, 03 Apr 2009 19:45:09 -0400 Subject: [Rxtx] Missing documentation In-Reply-To: <460801A4097E3D4CA04CC64EE648584809C8BD6F@ism-mail03.corp.ad.wrs.com> References: <49D43979.4050702@bbs.darktech.org> <49D5973E.4050400@bbs.darktech.org> <460801A4097E3D4CA04CC64EE648584809C8BD6F@ism-mail03.corp.ad.wrs.com> Message-ID: <49D69F85.3030804@bbs.darktech.org> You could always send Sun a formal email and ask for permission to copy their Javadoc. I doubt they would give you problems. Gili Oberhuber, Martin wrote: > Hello Gili, > > The classes in the gnu.io namespace are designed to work exactly > as their counterparts in the javax.comm namespace. Therefore, > if you just take the javax.comm Javadocs that's what you want. > > Unfortunately I don't think we can just copy & paste the > javax.comm Javadocs into RXTX due to license restrictions. > > I guess that's the main reason why RXTX is not (yet) Javadoc'd > as extensively as it should be. Actually, writing Javadocs > from scratch WITHOUT referencing the wording of the Sun > Javadocs is not that easy. > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] >> On Behalf Of cowwoc >> Sent: Freitag, 03. April 2009 06:58 >> To: rxtx at qbang.org >> Subject: [Rxtx] Missing documentation >> >> Hi, >> >> I noticed that RXTX 2.1 drops javax.comm support in favor >> of gnu.io. >> I have one major problem with this: the gui.io.* >> documentation is very >> poor. Many classes and methods have no Javadoc at all which >> makes them >> difficult to use. Please fix this for the final release. >> >> Thank you, >> Gili >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> From cowwoc at bbs.darktech.org Sat Apr 4 15:13:38 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sat, 04 Apr 2009 17:13:38 -0400 Subject: [Rxtx] Java5 support Message-ID: <49D7CD82.1040904@bbs.darktech.org> Now that you dropped javax.comm support, how about improving the API by replacing Enumation by Iterator, int by enum, and using Generics? It would improve the usability of the API. Gili From cowwoc at bbs.darktech.org Sat Apr 4 16:12:13 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sat, 04 Apr 2009 18:12:13 -0400 Subject: [Rxtx] RXTX Version mismatch in 2.2pre2 Message-ID: <49D7DB3D.5040008@bbs.darktech.org> When using RXTX-2.2pre2 I always get the following message: WARNING: RXTX Version mismatch Jar version = RXTX-2.2pre1 native lib Version = RXTX-2.2pre2 I have double checked that I am using the correct Jar file. Is this a known bug in pre2? Gili From tjarvi at qbang.org Sat Apr 4 16:48:53 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Apr 2009 16:48:53 -0600 (MDT) Subject: [Rxtx] RXTX Version mismatch in 2.2pre2 In-Reply-To: <49D7DB3D.5040008@bbs.darktech.org> References: <49D7DB3D.5040008@bbs.darktech.org> Message-ID: > When using RXTX-2.2pre2 I always get the following message: > > WARNING: RXTX Version mismatch > Jar version = RXTX-2.2pre1 > native lib Version = RXTX-2.2pre2 > Yep. You should still be able to test it. -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Sat Apr 4 16:50:43 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sat, 04 Apr 2009 18:50:43 -0400 Subject: [Rxtx] RXTX Version mismatch in 2.2pre2 In-Reply-To: References: <49D7DB3D.5040008@bbs.darktech.org> Message-ID: <49D7E443.9070404@bbs.darktech.org> In other words this is a known bug that will be fixed in the final version? Gili Trent Jarvi wrote: > > >> When using RXTX-2.2pre2 I always get the following message: >> >> WARNING: RXTX Version mismatch >> Jar version = RXTX-2.2pre1 >> native lib Version = RXTX-2.2pre2 >> > > Yep. > > You should still be able to test it. > > -- > Trent Jarvi > tjarvi at qbang.org From cowwoc at bbs.darktech.org Sat Apr 4 16:57:34 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sat, 04 Apr 2009 18:57:34 -0400 Subject: [Rxtx] IOException: Underlying input stream returned zero bytes Message-ID: <49D7E5DE.2050405@bbs.darktech.org> Hi, There seems to be a bug in RXTX 2.2pre2's handling of InputStream timeouts. If you open a serial port without ever invoking enableReceiveTimeout() then invoking InputStream.read() will always return 0 bytes right away. If you wrap the InputStream and invoke BufferedReader.readline() you will get the following exception: java.io.IOException: Underlying input stream returned zero bytes at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:268) [na:1.6.0_14-ea] at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:306) [na:1.6.0_14-ea] at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:158) [na:1.6.0_14-ea] at java.io.InputStreamReader.read(InputStreamReader.java:167) [na:1.6.0_14-ea] at java.io.BufferedReader.fill(BufferedReader.java:136) [na:1.6.0_14-ea] at java.io.BufferedReader.readLine(BufferedReader.java:299) [na:1.6.0_14-ea] at java.io.BufferedReader.readLine(BufferedReader.java:362) [na:1.6.0_14-ea] [snip] If you enable a timeout, the exception will only occur after the timeout expires. In short, it looks like RXTX is using a default timeout of zero (I am expecting it to block forever). It looks like other people have run into this as well: http://forums.sun.com/thread.jspa?threadID=5165346&start=10&tstart=0 Please confirm whether this is a known bug. Thank you, Gili From tjarvi at qbang.org Sat Apr 4 17:27:19 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Apr 2009 17:27:19 -0600 (MDT) Subject: [Rxtx] IOException: Underlying input stream returned zero bytes In-Reply-To: <49D7E5DE.2050405@bbs.darktech.org> References: <49D7E5DE.2050405@bbs.darktech.org> Message-ID: On Sat, 4 Apr 2009, cowwoc wrote: > Hi, > > There seems to be a bug in RXTX 2.2pre2's handling of InputStream > timeouts. If you open a serial port without ever invoking > enableReceiveTimeout() then invoking InputStream.read() will always > return 0 bytes right away. If you wrap the InputStream and invoke > BufferedReader.readline() you will get the following exception: > > java.io.IOException: Underlying input stream returned zero bytes > at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:268) > [na:1.6.0_14-ea] > at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:306) > [na:1.6.0_14-ea] > at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:158) > [na:1.6.0_14-ea] > at java.io.InputStreamReader.read(InputStreamReader.java:167) > [na:1.6.0_14-ea] > at java.io.BufferedReader.fill(BufferedReader.java:136) > [na:1.6.0_14-ea] > at java.io.BufferedReader.readLine(BufferedReader.java:299) > [na:1.6.0_14-ea] > at java.io.BufferedReader.readLine(BufferedReader.java:362) > [na:1.6.0_14-ea] > [snip] > > If you enable a timeout, the exception will only occur after the > timeout expires. In short, it looks like RXTX is using a default timeout > of zero (I am expecting it to block forever). It looks like other people > have run into this as well: > http://forums.sun.com/thread.jspa?threadID=5165346&start=10&tstart=0 > > Please confirm whether this is a known bug. > Hi Gili I've known about it but was not sure if it was a bug or not. It looks like we can treat it as a bug if nio is throwing an exception. Timeout and Thresholds are well documented in javax.comm but I didn't recall seeing defaults. For that reason, I've encouraged people to set the threshold and timeout to what they expect. Another note about InputStream.read(void): I noticed that I don't use that function at all while looking at code coverage results. Keep your eye out for additional issues. -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Sat Apr 4 19:03:29 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sat, 04 Apr 2009 21:03:29 -0400 Subject: [Rxtx] IOException: Underlying input stream returned zero bytes In-Reply-To: References: <49D7E5DE.2050405@bbs.darktech.org> Message-ID: <49D80361.7020801@bbs.darktech.org> Trent Jarvi wrote: > For that reason, I've encouraged people to set the threshold and timeout > to what they expect. It doesn't help. There doesn't seem to be a way to disable the timeout, even if you invoke disableReceiveTimeout() explicitly. Let me know when you put in a fix and I will test it. Thanks, Gili From cowwoc at bbs.darktech.org Sat Apr 4 23:27:25 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 01:27:25 -0400 Subject: [Rxtx] Crash in termios.c:892 Message-ID: <49D8413D.7040105@bbs.darktech.org> I can reproduce a crash in RXTX 2.2 pre2 100% of the time using my application code, but I can't seem to bring it down to a minimal testcase. Here is what I see: - thread begins running - open com1 - close com1 - open com5 - leave com5 open - thread shuts down - repeat the same process in a new thread - crash occurs when trying to open com1. Crash disappears if I close() com5 in the previous thread. The output window contains the following: # # A fatal error has been detected by the Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x05475cf6, pid=6064, tid=5436 # # JRE version: 6.0_14-b04 # Java VM: Java HotSpot(TM) Client VM (14.0-b13 mixed mode, sharing windows-x86 ) # Problematic frame: # C [rxtxSerial.dll+0x5cf6] # # An error report file with more information is saved as: # C:\Users\Gili\Documents\foobar\source\hs_err_pid6064.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp Error 0x5 at ..\src\termios.c(892): Access is denied. # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # Please let me know if the crash dump is enough to track down this bug. Thank you, Gili -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: hs_err_pid6064.log Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20090405/7133a1ce/attachment-0002.pl From cowwoc at bbs.darktech.org Sun Apr 5 00:24:19 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 02:24:19 -0400 Subject: [Rxtx] SerialPort.getName() is wrong Message-ID: <49D84E93.7050606@bbs.darktech.org> Sorry for all these emails but I keep on running into more issues. Here is what I noticed: - CommPortIdentifier.getPortIdentifier("COM5") returns a CommPortIdentifier where getName() == "COM5" - If, however, you invoke CommPortIdentifier.open() you get back a SerialPort where SerialPort.getName() is "//./COM5" I am expecting the name to remain consistent. "//./COM5" looks like an implementation detail and (as far as I can tell) it can't be used as an argument for any API method so it is somewhat useless. If getName() were to return "COM5" I could at least use it to get back the original CommPortIdentifier or compare against "known names" such as "COMx" or "LPTx". What do you think? Gili From tjarvi at qbang.org Sun Apr 5 10:18:42 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Apr 2009 10:18:42 -0600 (MDT) Subject: [Rxtx] SerialPort.getName() is wrong In-Reply-To: <49D84E93.7050606@bbs.darktech.org> References: <49D84E93.7050606@bbs.darktech.org> Message-ID: On Sun, 5 Apr 2009, cowwoc wrote: > > Sorry for all these emails but I keep on running into more issues. > Here is what I noticed: > > - CommPortIdentifier.getPortIdentifier("COM5") returns a > CommPortIdentifier where getName() == "COM5" > - If, however, you invoke CommPortIdentifier.open() you get back a > SerialPort where SerialPort.getName() is "//./COM5" > > I am expecting the name to remain consistent. "//./COM5" looks like > an implementation detail and (as far as I can tell) it can't be used as > an argument for any API method so it is somewhat useless. If getName() > were to return "COM5" I could at least use it to get back the original > CommPortIdentifier or compare against "known names" such as "COMx" or > "LPTx". What do you think? > Sure. If it itches enough you should be able to fix this in RXTXCommDriver.java. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Apr 5 10:27:58 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Apr 2009 10:27:58 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D8413D.7040105@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> Message-ID: On Sun, 5 Apr 2009, cowwoc wrote: > > I can reproduce a crash in RXTX 2.2 pre2 100% of the time using my > application code, but I can't seem to bring it down to a minimal testcase. > Here is what I see: > > - thread begins running > - open com1 > - close com1 > - open com5 > - leave com5 open > - thread shuts down > - repeat the same process in a new thread > - crash occurs when trying to open com1. Crash disappears if I close() com5 > in the previous thread. > > The output window contains the following: > > # > # A fatal error has been detected by the Java Runtime Environment: > # > # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x05475cf6, pid=6064, > tid=5436 > # > # JRE version: 6.0_14-b04 > # Java VM: Java HotSpot(TM) Client VM (14.0-b13 mixed mode, sharing > windows-x86 ) > # Problematic frame: > # C [rxtxSerial.dll+0x5cf6] > # > # An error report file with more information is saved as: > # C:\Users\Gili\Documents\foobar\source\hs_err_pid6064.log > # > # If you would like to submit a bug report, please visit: > # http://java.sun.com/webapps/bugreport/crash.jsp > Error 0x5 at ..\src\termios.c(892): Access is denied. > > > # The crash happened outside the Java Virtual Machine in native code. > # See problematic frame for where to report the bug. > # > > Please let me know if the crash dump is enough to track down this bug. > Hi Gili, You are responsible for cleaning up the serial ports when using threads. That said, if the thread did shut down, finalize should have been called if you are not passing the object around. See RXTXPort.java. protected void finalize() { if (debug) z.reportln( "RXTXPort:finalize()"); if( fd > 0 ) { if (debug) z.reportln( "RXTXPort:calling close()"); close(); } z.finalize(); } The exception is interesting. This is on Vista? Usually it just gives an open error when another process has the port. -- Trent Jarvi tjarvi at mathworks.com From cowwoc at bbs.darktech.org Sun Apr 5 10:35:55 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 12:35:55 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: References: <49D8413D.7040105@bbs.darktech.org> Message-ID: <49D8DDEB.5010908@bbs.darktech.org> Trent Jarvi wrote: > You are responsible for cleaning up the serial ports when using threads. > That said, if the thread did shut down, finalize should have been called > if you are not passing the object around. See RXTXPort.java. > > protected void finalize() > { > if (debug) > z.reportln( "RXTXPort:finalize()"); > if( fd > 0 ) > { > if (debug) > z.reportln( "RXTXPort:calling close()"); > close(); > } > z.finalize(); > } Two points: 1) One should never rely on finalizers because they may never run. 2) RXTX shouldn't cause the entire JVM to crash if I misuse the API. The native code should recover more gracefully. > The exception is interesting. This is on Vista? Usually it just gives > an open error when another process has the port. Yes, this is on Vista 64-bit. I'd really like to see this bug fixed. Is this code compilable under Visual Studio? If so, I can debug the problem on my end and send you a patch. Thanks, Gili From cowwoc at bbs.darktech.org Sun Apr 5 10:36:20 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 12:36:20 -0400 Subject: [Rxtx] SerialPort.getName() is wrong In-Reply-To: References: <49D84E93.7050606@bbs.darktech.org> Message-ID: <49D8DE04.6030306@bbs.darktech.org> Trent Jarvi wrote: >> I am expecting the name to remain consistent. "//./COM5" looks like >> an implementation detail and (as far as I can tell) it can't be used as >> an argument for any API method so it is somewhat useless. If getName() >> were to return "COM5" I could at least use it to get back the original >> CommPortIdentifier or compare against "known names" such as "COMx" or >> "LPTx". What do you think? >> > > Sure. > > If it itches enough you should be able to fix this in RXTXCommDriver.java. I'm not sure I understand. Are you saying that if I submit a patch you will commit it? Gili From tjarvi at qbang.org Sun Apr 5 10:46:23 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Apr 2009 10:46:23 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D8DDEB.5010908@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> Message-ID: On Sun, 5 Apr 2009, cowwoc wrote: > Trent Jarvi wrote: >> You are responsible for cleaning up the serial ports when using threads. >> That said, if the thread did shut down, finalize should have been called if >> you are not passing the object around. See RXTXPort.java. >> >> protected void finalize() >> { >> if (debug) >> z.reportln( "RXTXPort:finalize()"); >> if( fd > 0 ) >> { >> if (debug) >> z.reportln( "RXTXPort:calling close()"); >> close(); >> } >> z.finalize(); >> } > > Two points: > > 1) One should never rely on finalizers because they may never run. > 2) RXTX shouldn't cause the entire JVM to crash if I misuse the API. The > native code should recover more gracefully. > >> The exception is interesting. This is on Vista? Usually it just gives an >> open error when another process has the port. > > Yes, this is on Vista 64-bit. I'd really like to see this bug fixed. > Is this code compilable under Visual Studio? If so, I can debug the problem > on my end and send you a patch. > It will compile with the msvc cl.exe and nmake. See Makefile.msvc in the top level directory. You will need to adjust the JAVA_HOME variable. Also use the MSVC command prompt for x86_64 so cl and nmake are on your path. All the best, -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Apr 5 10:49:10 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Apr 2009 10:49:10 -0600 (MDT) Subject: [Rxtx] SerialPort.getName() is wrong In-Reply-To: <49D8DE04.6030306@bbs.darktech.org> References: <49D84E93.7050606@bbs.darktech.org> <49D8DE04.6030306@bbs.darktech.org> Message-ID: On Sun, 5 Apr 2009, cowwoc wrote: > Trent Jarvi wrote: >>> I am expecting the name to remain consistent. "//./COM5" looks like >>> an implementation detail and (as far as I can tell) it can't be used as >>> an argument for any API method so it is somewhat useless. If getName() >>> were to return "COM5" I could at least use it to get back the original >>> CommPortIdentifier or compare against "known names" such as "COMx" or >>> "LPTx". What do you think? >>> >> >> Sure. >> >> If it itches enough you should be able to fix this in RXTXCommDriver.java. > > I'm not sure I understand. Are you saying that if I submit a patch > you will commit it? > Hi Gili, Post a patch here and if nobody complains, we will commit it and give you credit. Yep. Other issues like changing the API to use java5 that may break existing apps are likely to run into objections but bug fixes usually get fixed just as you mention. -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Sun Apr 5 10:55:07 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 12:55:07 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> Message-ID: <49D8E26B.2040705@bbs.darktech.org> Trent Jarvi wrote: > It will compile with the msvc cl.exe and nmake. See Makefile.msvc in > the top level directory. You will need to adjust the JAVA_HOME > variable. Also use the MSVC command prompt for x86_64 so cl and nmake > are on your path. This is very odd. The CVS version of the code does not contain this file. Do you keep the latest code somewhere else? Gili From cowwoc at bbs.darktech.org Sun Apr 5 11:01:58 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 13:01:58 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D8E26B.2040705@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> Message-ID: <49D8E406.10708@bbs.darktech.org> cowwoc wrote: > Trent Jarvi wrote: >> It will compile with the msvc cl.exe and nmake. See Makefile.msvc in >> the top level directory. You will need to adjust the JAVA_HOME >> variable. Also use the MSVC command prompt for x86_64 so cl and nmake >> are on your path. > > This is very odd. The CVS version of the code does not contain this > file. Do you keep the latest code somewhere else? Okay I figured it out. CVS head is out of date, the "commapi-0-0-1" revision contains the correct files. Gili From tjarvi at qbang.org Sun Apr 5 11:05:43 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Apr 2009 11:05:43 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D8E26B.2040705@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> Message-ID: CVS HEAD is currently the rxtx 2.0 code. A branch was created long ago for 'experimental' gnu.io work. It just happens that the branch is what everyone uses now. checkout -r commapi-0-0-1 rxtx-devel will get the branch On Sun, 5 Apr 2009, cowwoc wrote: > Trent Jarvi wrote: >> It will compile with the msvc cl.exe and nmake. See Makefile.msvc in the >> top level directory. You will need to adjust the JAVA_HOME variable. Also >> use the MSVC command prompt for x86_64 so cl and nmake are on your path. > > This is very odd. The CVS version of the code does not contain this > file. Do you keep the latest code somewhere else? > > Gili > From cowwoc at bbs.darktech.org Sun Apr 5 14:50:47 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 16:50:47 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> Message-ID: <49D919A7.1070806@bbs.darktech.org> Okay, I tracked down the crash. It's being caused by YACK() using a 80-character buffer. The error message is longer than 80 characters, so _snprintf_s() crashes to avoid a buffer overflow. Please apply the attached patch and add the zipped up Visual Studio project directory. It's not perfect yet but it's a good start. Gili Trent Jarvi wrote: > > CVS HEAD is currently the rxtx 2.0 code. A branch was created long > ago for 'experimental' gnu.io work. It just happens that the branch > is what everyone uses now. > > checkout -r commapi-0-0-1 rxtx-devel > > will get the branch > > On Sun, 5 Apr 2009, cowwoc wrote: > >> Trent Jarvi wrote: >>> It will compile with the msvc cl.exe and nmake. See Makefile.msvc >>> in the top level directory. You will need to adjust the JAVA_HOME >>> variable. Also use the MSVC command prompt for x86_64 so cl and >>> nmake are on your path. >> >> This is very odd. The CVS version of the code does not contain >> this file. Do you keep the latest code somewhere else? >> >> Gili >> -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx-devel.patch Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20090405/d9b82962/attachment-0001.pl -------------- next part -------------- A non-text attachment was scrubbed... Name: Win32.zip Type: application/octet-stream Size: 17764 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20090405/d9b82962/attachment-0003.obj From cowwoc at bbs.darktech.org Sun Apr 5 15:22:01 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 17:22:01 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D919A7.1070806@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> <49D919A7.1070806@bbs.darktech.org> Message-ID: <49D920F9.6080702@bbs.darktech.org> My mistake. The problem in YACK is real, but it isn't the real cause of the crash. The crash is caused by termios.c line 1099: index->prev->next = port; because in my case "index->prev==0". I think the bug is that the code assumes that index will contain a minimum of two entries if we're inserting a previously closed fd. In my case, it only contains one. I'm not sure why you have this code branch (as opposed to appending to the end of index). Please take a look. Thanks, Gili cowwoc wrote: > > Okay, I tracked down the crash. It's being caused by YACK() using a > 80-character buffer. The error message is longer than 80 characters, so > _snprintf_s() crashes to avoid a buffer overflow. > > Please apply the attached patch and add the zipped up Visual Studio > project directory. It's not perfect yet but it's a good start. > > Gili > > Trent Jarvi wrote: >> >> CVS HEAD is currently the rxtx 2.0 code. A branch was created long >> ago for 'experimental' gnu.io work. It just happens that the branch >> is what everyone uses now. >> >> checkout -r commapi-0-0-1 rxtx-devel >> >> will get the branch >> >> On Sun, 5 Apr 2009, cowwoc wrote: >> >>> Trent Jarvi wrote: >>>> It will compile with the msvc cl.exe and nmake. See Makefile.msvc >>>> in the top level directory. You will need to adjust the JAVA_HOME >>>> variable. Also use the MSVC command prompt for x86_64 so cl and >>>> nmake are on your path. >>> >>> This is very odd. The CVS version of the code does not contain >>> this file. Do you keep the latest code somewhere else? >>> >>> Gili >>> From tjarvi at qbang.org Sun Apr 5 16:13:27 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Apr 2009 16:13:27 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D920F9.6080702@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> <49D919A7.1070806@bbs.darktech.org> <49D920F9.6080702@bbs.darktech.org> Message-ID: Hi Gili, Are you using the cvs version? I thought we fixed the linked list issues. A solution was posted to the list. Let me look at work tomorrow to see what I have. On Sun, 5 Apr 2009, cowwoc wrote: > > My mistake. The problem in YACK is real, but it isn't the real cause > of the crash. The crash is caused by termios.c line 1099: > > index->prev->next = port; > > because in my case "index->prev==0". I think the bug is that the code > assumes that index will contain a minimum of two entries if we're inserting a > previously closed fd. In my case, it only contains one. > > I'm not sure why you have this code branch (as opposed to appending > to the end of index). Please take a look. > > Thanks, > Gili > > cowwoc wrote: >> >> Okay, I tracked down the crash. It's being caused by YACK() using a >> 80-character buffer. The error message is longer than 80 characters, so >> _snprintf_s() crashes to avoid a buffer overflow. >> >> Please apply the attached patch and add the zipped up Visual Studio >> project directory. It's not perfect yet but it's a good start. >> >> Gili >> >> Trent Jarvi wrote: >>> >>> CVS HEAD is currently the rxtx 2.0 code. A branch was created long ago >>> for 'experimental' gnu.io work. It just happens that the branch is what >>> everyone uses now. >>> >>> checkout -r commapi-0-0-1 rxtx-devel >>> >>> will get the branch >>> >>> On Sun, 5 Apr 2009, cowwoc wrote: >>> >>>> Trent Jarvi wrote: >>>>> It will compile with the msvc cl.exe and nmake. See Makefile.msvc in >>>>> the top level directory. You will need to adjust the JAVA_HOME >>>>> variable. Also use the MSVC command prompt for x86_64 so cl and nmake >>>>> are on your path. >>>> >>>> This is very odd. The CVS version of the code does not contain this >>>> file. Do you keep the latest code somewhere else? >>>> >>>> Gili >>>> > From ilkka at myller.com Sun Apr 5 23:58:08 2009 From: ilkka at myller.com (Ilkka Myller) Date: Mon, 6 Apr 2009 08:58:08 +0300 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> <49D919A7.1070806@bbs.darktech.org> <49D920F9.6080702@bbs.darktech.org> Message-ID: <19779C97-E0C7-4E3D-B715-F84F50F00CE6@myller.com> Hi all, I've already submitted the patch to fix this issue in february: http://mailman.qbang.org/pipermail/rxtx/2009-February/3989441.html The patch fixes the mentioned doubly linked list handling in termios.c -- I Trent Jarvi kirjoitti 6.4.2009 kello 1.13: > > Hi Gili, > > Are you using the cvs version? I thought we fixed the linked list > issues. > A solution was posted to the list. Let me look at work tomorrow to > see > what I have. > > > > On Sun, 5 Apr 2009, cowwoc wrote: > >> >> My mistake. The problem in YACK is real, but it isn't the real cause >> of the crash. The crash is caused by termios.c line 1099: >> >> index->prev->next = port; >> >> because in my case "index->prev==0". I think the bug is that the >> code >> assumes that index will contain a minimum of two entries if we're >> inserting a >> previously closed fd. In my case, it only contains one. >> >> I'm not sure why you have this code branch (as opposed to appending >> to the end of index). Please take a look. >> >> Thanks, >> Gili >> >> cowwoc wrote: >>> >>> Okay, I tracked down the crash. It's being caused by YACK() >>> using a >>> 80-character buffer. The error message is longer than 80 >>> characters, so >>> _snprintf_s() crashes to avoid a buffer overflow. >>> >>> Please apply the attached patch and add the zipped up Visual >>> Studio >>> project directory. It's not perfect yet but it's a good start. >>> >>> Gili >>> >>> Trent Jarvi wrote: >>>> >>>> CVS HEAD is currently the rxtx 2.0 code. A branch was created >>>> long ago >>>> for 'experimental' gnu.io work. It just happens that the branch >>>> is what >>>> everyone uses now. >>>> >>>> checkout -r commapi-0-0-1 rxtx-devel >>>> >>>> will get the branch >>>> >>>> On Sun, 5 Apr 2009, cowwoc wrote: >>>> >>>>> Trent Jarvi wrote: >>>>>> It will compile with the msvc cl.exe and nmake. See >>>>>> Makefile.msvc in >>>>>> the top level directory. You will need to adjust the JAVA_HOME >>>>>> variable. Also use the MSVC command prompt for x86_64 so cl and >>>>>> nmake >>>>>> are on your path. >>>>> >>>>> This is very odd. The CVS version of the code does not >>>>> contain this >>>>> file. Do you keep the latest code somewhere else? >>>>> >>>>> Gili >>>>> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Steffen.DETTMER at ingenico.com Mon Apr 6 02:53:47 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 6 Apr 2009 10:53:47 +0200 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D919A7.1070806@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> <49D919A7.1070806@bbs.darktech.org> Message-ID: <20090406085347.GM8289@elberon.bln.de.ingenico.com> Hi, just two minor details, first about the errno change, I though #include extern int errno; is correct (POSIX.1) - why this change? second about the log message, I think the maximum length could be limited and the return value of malloc must be checked for != NULL before using. Should it be _snprintf_s( message, 80, _TRUNCATE, "Error 0x%x at %s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); (I know that MS-CRT _snprintf does not guarantee to have a final EOS, but I think _snprintf_s with _TRUNCATE does so?). If it is known that truncation may happen maybe sizeof[message] could be increased; maybe using some %.20s could be used avoiding __FILE__ including big pathes to a message where all the message had been cut-off. To have it portable I think it could be: /* generally: */ #if defined(_MSC_VER) # define snprintf _snprintf #endif snprintf(message, sizeof(message), "Error 0x%x at %.20s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); message[sizeof(message)-1] = '\0'; /* needed for MS CRT snprintf */ (for length and size parameter I think size_t could be an option, but on several platforms, including MS-CRT and older glibc, there is no %z, unfortunately) oki, Steffen * cowwoc wrote on Sun, Apr 05, 2009 at 16:50 -0400: > > Okay, I tracked down the crash. It's being caused by YACK() using a > 80-character buffer. The error message is longer than 80 characters, so > _snprintf_s() crashes to avoid a buffer overflow. > > Please apply the attached patch and add the zipped up Visual Studio > project directory. It's not perfect yet but it's a good start. > > Gili > > Trent Jarvi wrote: > > > >CVS HEAD is currently the rxtx 2.0 code. A branch was created long > >ago for 'experimental' gnu.io work. It just happens that the branch > >is what everyone uses now. > > > >checkout -r commapi-0-0-1 rxtx-devel > > > >will get the branch > > > >On Sun, 5 Apr 2009, cowwoc wrote: > > > >>Trent Jarvi wrote: > >>>It will compile with the msvc cl.exe and nmake. See Makefile.msvc > >>>in the top level directory. You will need to adjust the JAVA_HOME > >>>variable. Also use the MSVC command prompt for x86_64 so cl and > >>>nmake are on your path. > >> > >> This is very odd. The CVS version of the code does not contain > >>this file. Do you keep the latest code somewhere else? > >> > >>Gili > >> > Index: ParallelImp.c > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/ParallelImp.c,v > retrieving revision 1.15.2.36 > diff -u -r1.15.2.36 ParallelImp.c > --- ParallelImp.c 11 Feb 2009 01:04:19 -0000 1.15.2.36 > +++ ParallelImp.c 5 Apr 2009 17:55:23 -0000 > @@ -119,7 +119,7 @@ > # include > #endif > > -extern int errno; > +_CRTIMP extern int * __cdecl _errno(void); > > #include "ParallelImp.h" > > @@ -181,8 +181,6 @@ > > #if defined (WIN32) > > -#define CTL_CODE( DeviceType, Function, Method, Access ) (((DeviceType) << 16) | ((Access) << 14) | ((Function) << 2) | (Method)) > - > #define FILE_DEVICE_PARALLEL_PORT 0x00000016 > #define METHOD_BUFFERED 0 > #define FILE_ANY_ACCESS 0 > @@ -253,7 +251,6 @@ > jobject jobj) > { > int fd = get_java_var( env, jobj,"fd","I" ); > - int status; > #if defined (__linux__) > ioctl(fd, LPGETSTATUS, &status); > #elif defined (WIN32) > Index: SerialImp.c > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v > retrieving revision 1.46.2.203 > diff -u -r1.46.2.203 SerialImp.c > --- SerialImp.c 19 Mar 2009 03:27:48 -0000 1.46.2.203 > +++ SerialImp.c 5 Apr 2009 17:49:48 -0000 > @@ -147,7 +147,7 @@ > #include > #endif /* LIBLOCKDEV */ > > -extern int errno; > +_CRTIMP extern int * __cdecl _errno(void); > > #include "SerialImp.h" > > Index: termios.c > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/termios.c,v > retrieving revision 1.9.2.62 > diff -u -r1.9.2.62 termios.c > --- termios.c 13 Jan 2009 03:08:55 -0000 1.9.2.62 > +++ termios.c 5 Apr 2009 17:54:09 -0000 > @@ -88,7 +88,7 @@ > #define SIGIO 0 > > int my_errno; > -extern int errno; > +_CRTIMP extern int * __cdecl _errno(void); > struct termios_list > { > char filename[80]; > @@ -1350,7 +1350,7 @@ > In that case use EAGAIN. See SerialImp.c:testRead() > ----------------------------------------------------------*/ > > -int serial_read( int fd, void *vb, int size ) > +int serial_read( int fd, void *vb, unsigned int size ) > { > long start, now; > unsigned long nBytes = 0, total = 0, error; > Index: win32termios.h > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/win32termios.h,v > retrieving revision 1.5.2.34 > diff -u -r1.5.2.34 win32termios.h > --- win32termios.h 5 Feb 2009 01:25:05 -0000 1.5.2.34 > +++ win32termios.h 5 Apr 2009 20:29:30 -0000 > @@ -60,6 +60,7 @@ > #include > #include > #include > +#include > #ifdef TRACE > #define ENTER(x) report("entering "x" \n"); > #define LEAVE(x) report("leaving "x" \n"); > @@ -70,8 +71,9 @@ > #if defined(_MSC_VER) > #define YACK() \ > { \ > - char *allocTextBuf, message[80]; \ > - unsigned long nChars; \ > + char *allocTextBuf, *message; \ > + const unsigned short longestNumber = 20; \ > + unsigned long nChars, len; \ > unsigned int errorCode = GetLastError(); \ > nChars = FormatMessage ( \ > FORMAT_MESSAGE_ALLOCATE_BUFFER | \ > @@ -82,8 +84,12 @@ > (LPSTR)&allocTextBuf, \ > 16, \ > NULL ); \ > - _snprintf_s( message, 80, 80, "Error 0x%x at %s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); \ > + len = strlen("Error 0x") + longestNumber + strlen(" at ") + strlen(__FILE__) + longestNumber + \ > + strlen(": ") + ((nChars+1) * sizeof(TCHAR)) + 1; \ > + message = malloc(len); \ > + _snprintf_s( message, len, len - 1, "Error 0x%x at %s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); \ > report_error( message ); \ > + free(message); \ > LocalFree(allocTextBuf); \ > Sleep(1); \ > } > @@ -173,7 +179,7 @@ > int serial_test( char * ); > int serial_open(const char *File, int flags, ... ); > int serial_close(int fd); > -int serial_read(int fd, void *b, int size); > +int serial_read(int fd, void *b, unsigned int size); > int serial_write(int fd, char *Str, int length); > /* > * lcc winsock.h conflicts > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx End of message. ------------------------------------------------------------------->8======= About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From bill7007 at gmail.com Mon Apr 6 16:34:50 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Mon, 6 Apr 2009 18:34:50 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: <49D693BA.8060909@gatworks.com> References: <49D546F8.20807@gatworks.com> <49D693BA.8060909@gatworks.com> Message-ID: Once it hung, three stack dumps minutes apart were exactly the same. I have a noticed that when it hangs, the read appears after flush() enter and before flush leave() that doesn't happen like: RXTXPort:SerialOutputStream:flush() enter RXTXPort:SerialInputStream:read(8192 0 8192) called When it works, flush() enter and leave happen together. It may just be because flush() hangs and read is the only other thread waiting to run at that point. I don't know much about the RXTX design and kernel interaction, just digging through the code some. Is there a design description somewhere? Am hung up on target system compile since UTS_RELEASE seems no longer defined for 2.6.18 up kernels and have not figured a good patch yet. But, that is another issue. Thanks for the good help. On Fri, Apr 3, 2009 at 6:54 PM, U. George wrote: > I would have tried 2 or 3 "^\" . If things are stuck, then all will be at > same 'java' instruction. If thread is moving, then one of the snapshots > would be different. > > I *think* flushing/draining wont return until the kernel buffers to device > have been accepted by device. Stuck/paused device? > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090406/c4b509d8/attachment-0002.html From tjarvi at qbang.org Mon Apr 6 17:45:38 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 6 Apr 2009 17:45:38 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <20090406085347.GM8289@elberon.bln.de.ingenico.com> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> <49D919A7.1070806@bbs.darktech.org> <20090406085347.GM8289@elberon.bln.de.ingenico.com> Message-ID: The error bits in the patch can probably just be dropped out. I don't see what they solve. Your snprintf define appears to work. The following is what I'd like to put in if noone objects. #if defined(_MSC_VER) # define snprintf _snprintf #endif #define YACK() \ { \ char *allocTextBuf, message[80]; \ unsigned long nChars; \ unsigned int errorCode = GetLastError(); \ nChars = FormatMessage ( \ FORMAT_MESSAGE_ALLOCATE_BUFFER | \ FORMAT_MESSAGE_FROM_SYSTEM, \ NULL, \ errorCode, \ MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT), \ (LPSTR)&allocTextBuf, \ 16, \ NULL ); \ snprintf( message, 80, "Error 0x%x at %s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); \ message[sizeof(message)-1] = '\0'; /* needed for MS CRT snprintf */ \ report_error( message ); \ LocalFree(allocTextBuf); \ Sleep(1); \ } On Mon, 6 Apr 2009, Steffen DETTMER wrote: > Hi, > > just two minor details, first about the errno change, I though > > #include > extern int errno; > > is correct (POSIX.1) - why this change? > > second about the log message, I think the maximum length could be > limited and the return value of malloc must be checked for != > NULL before using. > > Should it be > > _snprintf_s( message, 80, _TRUNCATE, "Error 0x%x at %s(%d): %s\n", > errorCode, __FILE__, __LINE__, allocTextBuf); > > (I know that MS-CRT _snprintf does not guarantee to have a final > EOS, but I think _snprintf_s with _TRUNCATE does so?). > > If it is known that truncation may happen maybe sizeof[message] > could be increased; maybe using some %.20s could be used avoiding > __FILE__ including big pathes to a message where all the message > had been cut-off. > > To have it portable I think it could be: > > /* generally: */ > #if defined(_MSC_VER) > # define snprintf _snprintf > #endif > > snprintf(message, sizeof(message), "Error 0x%x at %.20s(%d): %s\n", > errorCode, __FILE__, __LINE__, allocTextBuf); > message[sizeof(message)-1] = '\0'; /* needed for MS CRT snprintf */ > > (for length and size parameter I think size_t could be an option, > but on several platforms, including MS-CRT and older glibc, > there is no %z, unfortunately) > > oki, > > Steffen > > > * cowwoc wrote on Sun, Apr 05, 2009 at 16:50 -0400: >> >> Okay, I tracked down the crash. It's being caused by YACK() using a >> 80-character buffer. The error message is longer than 80 characters, so >> _snprintf_s() crashes to avoid a buffer overflow. >> >> Please apply the attached patch and add the zipped up Visual Studio >> project directory. It's not perfect yet but it's a good start. >> >> Gili >> >> Trent Jarvi wrote: >> > >> >CVS HEAD is currently the rxtx 2.0 code. A branch was created long >> >ago for 'experimental' gnu.io work. It just happens that the branch >> >is what everyone uses now. >> > >> >checkout -r commapi-0-0-1 rxtx-devel >> > >> >will get the branch >> > >> >On Sun, 5 Apr 2009, cowwoc wrote: >> > >> >>Trent Jarvi wrote: >> >>>It will compile with the msvc cl.exe and nmake. See Makefile.msvc >> >>>in the top level directory. You will need to adjust the JAVA_HOME >> >>>variable. Also use the MSVC command prompt for x86_64 so cl and >> >>>nmake are on your path. >> >> >> >> This is very odd. The CVS version of the code does not contain >> >>this file. Do you keep the latest code somewhere else? >> >> >> >>Gili >> >> > >> Index: ParallelImp.c >> =================================================================== >> RCS file: /usr/local/cvsroot/rxtx-devel/src/ParallelImp.c,v >> retrieving revision 1.15.2.36 >> diff -u -r1.15.2.36 ParallelImp.c >> --- ParallelImp.c 11 Feb 2009 01:04:19 -0000 1.15.2.36 >> +++ ParallelImp.c 5 Apr 2009 17:55:23 -0000 >> @@ -119,7 +119,7 @@ >> # include >> #endif >> >> -extern int errno; >> +_CRTIMP extern int * __cdecl _errno(void); >> >> #include "ParallelImp.h" >> >> @@ -181,8 +181,6 @@ >> >> #if defined (WIN32) >> >> -#define CTL_CODE( DeviceType, Function, Method, Access ) (((DeviceType) << 16) | ((Access) << 14) | ((Function) << 2) | (Method)) >> - >> #define FILE_DEVICE_PARALLEL_PORT 0x00000016 >> #define METHOD_BUFFERED 0 >> #define FILE_ANY_ACCESS 0 >> @@ -253,7 +251,6 @@ >> jobject jobj) >> { >> int fd = get_java_var( env, jobj,"fd","I" ); >> - int status; >> #if defined (__linux__) >> ioctl(fd, LPGETSTATUS, &status); >> #elif defined (WIN32) >> Index: SerialImp.c >> =================================================================== >> RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v >> retrieving revision 1.46.2.203 >> diff -u -r1.46.2.203 SerialImp.c >> --- SerialImp.c 19 Mar 2009 03:27:48 -0000 1.46.2.203 >> +++ SerialImp.c 5 Apr 2009 17:49:48 -0000 >> @@ -147,7 +147,7 @@ >> #include >> #endif /* LIBLOCKDEV */ >> >> -extern int errno; >> +_CRTIMP extern int * __cdecl _errno(void); >> >> #include "SerialImp.h" >> >> Index: termios.c >> =================================================================== >> RCS file: /usr/local/cvsroot/rxtx-devel/src/termios.c,v >> retrieving revision 1.9.2.62 >> diff -u -r1.9.2.62 termios.c >> --- termios.c 13 Jan 2009 03:08:55 -0000 1.9.2.62 >> +++ termios.c 5 Apr 2009 17:54:09 -0000 >> @@ -88,7 +88,7 @@ >> #define SIGIO 0 >> >> int my_errno; >> -extern int errno; >> +_CRTIMP extern int * __cdecl _errno(void); >> struct termios_list >> { >> char filename[80]; >> @@ -1350,7 +1350,7 @@ >> In that case use EAGAIN. See SerialImp.c:testRead() >> ----------------------------------------------------------*/ >> >> -int serial_read( int fd, void *vb, int size ) >> +int serial_read( int fd, void *vb, unsigned int size ) >> { >> long start, now; >> unsigned long nBytes = 0, total = 0, error; >> Index: win32termios.h >> =================================================================== >> RCS file: /usr/local/cvsroot/rxtx-devel/src/win32termios.h,v >> retrieving revision 1.5.2.34 >> diff -u -r1.5.2.34 win32termios.h >> --- win32termios.h 5 Feb 2009 01:25:05 -0000 1.5.2.34 >> +++ win32termios.h 5 Apr 2009 20:29:30 -0000 >> @@ -60,6 +60,7 @@ >> #include >> #include >> #include >> +#include >> #ifdef TRACE >> #define ENTER(x) report("entering "x" \n"); >> #define LEAVE(x) report("leaving "x" \n"); >> @@ -70,8 +71,9 @@ >> #if defined(_MSC_VER) >> #define YACK() \ >> { \ >> - char *allocTextBuf, message[80]; \ >> - unsigned long nChars; \ >> + char *allocTextBuf, *message; \ >> + const unsigned short longestNumber = 20; \ >> + unsigned long nChars, len; \ >> unsigned int errorCode = GetLastError(); \ >> nChars = FormatMessage ( \ >> FORMAT_MESSAGE_ALLOCATE_BUFFER | \ >> @@ -82,8 +84,12 @@ >> (LPSTR)&allocTextBuf, \ >> 16, \ >> NULL ); \ >> - _snprintf_s( message, 80, 80, "Error 0x%x at %s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); \ >> + len = strlen("Error 0x") + longestNumber + strlen(" at ") + strlen(__FILE__) + longestNumber + \ >> + strlen(": ") + ((nChars+1) * sizeof(TCHAR)) + 1; \ >> + message = malloc(len); \ >> + _snprintf_s( message, len, len - 1, "Error 0x%x at %s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); \ >> report_error( message ); \ >> + free(message); \ >> LocalFree(allocTextBuf); \ >> Sleep(1); \ >> } >> @@ -173,7 +179,7 @@ >> int serial_test( char * ); >> int serial_open(const char *File, int flags, ... ); >> int serial_close(int fd); >> -int serial_read(int fd, void *b, int size); >> +int serial_read(int fd, void *b, unsigned int size); >> int serial_write(int fd, char *Str, int length); >> /* >> * lcc winsock.h conflicts >> > > >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > > > > > > > > > > > > End of message. > ------------------------------------------------------------------->8======= > > > About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. > This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > P Please consider the environment before printing this e-mail > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Apr 6 18:11:28 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 6 Apr 2009 18:11:28 -0600 (MDT) Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: <49D546F8.20807@gatworks.com> <49D693BA.8060909@gatworks.com> Message-ID: UTS_RELEASE is defined in now. The check really should be removed from RXTX. It was a defensive check for wilder times when GNU glibc did not have defines the kernel headers had so rxtx would include the kernel headers instead. :/ If you don't have linux/version.h, it is generated when you configure the kernel. make oldconfig used to do the trick. It may make sense to work with the prerelease or CVS code. RXTX just assumes that flush, read and anything else the kernel exposes may be called at anytime from any thread. There isn't a design for the kernel interaction. There are higher level constraints put in Java to prevent some things happening at the same time with 'synchronized.' RXTXPort.java has all of those. When the port is opened, a native event thread is started which uses select to know if an event has happened. BSD like systems have a native thread that fires off on write which tries to flush() to determine when the output buffer is empty asynchronously. The rest is not marshaled in any fashion at the native level. T I think there is a lower level deadlock being triggered in flush as well. I don't think it should be possible if everything was right underneath us. You may want to examine the java code closer to make sure it isnt possible the lock is there. On Mon, 6 Apr 2009, Bill Johnson wrote: > Once it hung, three stack dumps minutes apart were exactly the same. > I have a noticed that when it hangs, the read appears after flush() enter and > before flush leave() that doesn't happen like: > RXTXPort:SerialOutputStream:flush() enter > RXTXPort:SerialInputStream:read(8192 0 8192) called > > When it works, flush() enter and leave happen together. It may just be because > flush() hangs and read is the only other thread waiting to run at that point. > I don't know much about the RXTX design and kernel interaction, just digging > through the code some. Is there a design description somewhere? > > Am hung up on target system compile since UTS_RELEASE seems no longer defined for > 2.6.18 up kernels and have not figured a good patch yet. But, that is another > issue. > > Thanks for the good help. > > > On Fri, Apr 3, 2009 at 6:54 PM, U. George wrote: > I would have tried 2 or 3 "^\" . If things are stuck, then all will be > at same 'java' instruction. If thread is moving, then one of the > snapshots would be different. > > I *think* flushing/draining wont return until the kernel buffers to > device have been accepted by device. Stuck/paused device? > > > > > From tjarvi at qbang.org Mon Apr 6 18:28:50 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 6 Apr 2009 18:28:50 -0600 (MDT) Subject: [Rxtx] CVS updates. Pre3 is comming. Message-ID: I need to go through the bugzilla reports prior to the pre3 release. I think this should be close if you want to check it out from CVS. added: YACK() debug overflow fix for windows Steffen DETTMER (and many others) multiport fix for windows. Ilkka Myller http://mailman.qbang.org/pipermail/rxtx/2009-February/3989441.html I think this code is current. If I missed something, yell. CVS Info: export/setenv CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login # passwd mousy cvs checkout -r commapi-0-0-1 rxtx-devel -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Apr 6 22:32:07 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 6 Apr 2009 22:32:07 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D919A7.1070806@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> <49D919A7.1070806@bbs.darktech.org> Message-ID: Ah. I'll put this in CVS tomorrow. I did sync up the code with my work sandbox today. I just forgot to pull and add this. On Sun, 5 Apr 2009, cowwoc wrote: > > Okay, I tracked down the crash. It's being caused by YACK() using a > 80-character buffer. The error message is longer than 80 characters, so > _snprintf_s() crashes to avoid a buffer overflow. > > Please apply the attached patch and add the zipped up Visual Studio > project directory. It's not perfect yet but it's a good start. > > Gili > > Trent Jarvi wrote: >> >> CVS HEAD is currently the rxtx 2.0 code. A branch was created long ago for >> 'experimental' gnu.io work. It just happens that the branch is what >> everyone uses now. >> >> checkout -r commapi-0-0-1 rxtx-devel >> >> will get the branch >> >> On Sun, 5 Apr 2009, cowwoc wrote: >> >>> Trent Jarvi wrote: >>>> It will compile with the msvc cl.exe and nmake. See Makefile.msvc in the >>>> top level directory. You will need to adjust the JAVA_HOME variable. >>>> Also use the MSVC command prompt for x86_64 so cl and nmake are on your >>>> path. >>> >>> This is very odd. The CVS version of the code does not contain this >>> file. Do you keep the latest code somewhere else? >>> >>> Gili >>> > From cowwoc at bbs.darktech.org Tue Apr 7 06:07:46 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Tue, 07 Apr 2009 08:07:46 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: References: Message-ID: <49DB4212.40807@bbs.darktech.org> > just two minor details, first about the errno change, I though > > #include > extern int errno; > > is correct (POSIX.1) - why this change? If you compile this under Visual Studio 2008 you will get warnings that the errno type being imported is different from the type being exported. The definition I pasted is the one being exported. Perhaps we should use #ifdef WIN32 for this? Gili From bill7007 at gmail.com Tue Apr 7 17:58:54 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Tue, 7 Apr 2009 19:58:54 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: <49D546F8.20807@gatworks.com> <49D693BA.8060909@gatworks.com> Message-ID: I have traced the hang down to a call to tcdrain(fd) in SerialImp.c:drain() running and rebuilt under Netbeans on the target machine with debug messages on. That puts it into the system code, so I'm not sure how to proceed. I guess I could debug into the kernel source but I've not done that. I saw some discussion about an IOCTL that sets/adjusts a timeout on tcdrain() but that may have been for BSD. Maybe there is some new setup requirement or bug introduced with this 2.6.18 kernel or a hardware difference. Below is a message listing with some of the repeated parts removed. Maybe you can see something noteworthy? JNI_OnLoad called. WARNING: RXTX Version mismatch Jar version = RXTX-2.2pre2 native lib Version = RXTX-2.2pre3 entering RXTXCommDriver:getDeviceDirectory entering RXTXPort:testRead fhs_lock: creating lockfile: 29704 fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXPort:testRead RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB2 fhs_lock: creating lockfile: 29704 fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXPort:testRead RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB1 fhs_lock: creating lockfile: 29704 fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXPort:testRead RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB0 fhs_lock: creating lockfile: 29704 fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXPort:testRead fhs_lock: creating lockfile: 29704 ... REPEATS fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXPort:testRead fhs_lock: creating lockfile: 29704 fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXCommDriver:getDeviceDirectory entering RXTXPort:testRead fhs_lock: creating lockfile: 29704 ...REPEATS fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXPort:testRead fhs_lock: creating lockfile: 29704 fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXPort:Initialize RXTX WARNING: This library was compiled to run with OS release 2.6.18 and you are currently running OS release 2.6.18-92.1.6.el5. In some cases this can be a problem. Try recompiling RXTX if you notice strange behavior. If you just compiled RXTX make sure /usr/include/linux is a symbolic link to the include files that came with the kernel source and not an older copy. press enter to continue leaving RXTXPort:Initialize entering RXTXPort:open fhs_lock: creating lockfile: 29704 open: locking worked for /dev/ttyUSB2 open: fd returned is 9 leaving RXTXPort:open entering eventLoop has_line_status_register_acess: Port does not support TIOCSERGETLSR driver_has_tiocgicount: Port does not support TIOCGICOUNT events init_threads: get eis init_threads: set eis init_threads: stop leaving RXTXPort:translate_speed entering RXTXPort:nativeSetSerialPortParams entering translate_date_bits entering translate_stop_bits leaving RXTXPort:translate_stop_bits entering translate_parity leaving translate_parity entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 ...REPEATS entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 leaving RXTXPort:nativeSetSerialPortParams entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 ...REPEATS entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 entering writeArray entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 writeArray() leaving RXTXPort:writeArray entering SerialImp.c:drain() nativeDrain: trying tcdrain RXTXPort:drain() returns: 0 leaving RXTXPort:drain() entering writeArray writeArray() leaving RXTXPort:writeArray entering SerialImp.c:drain() nativeDrain: trying tcdrain entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 Tue Apr 07 18:51:49 EDT 2009:TSerial[22]:Using Port:/dev/ttyUSB2 Tue Apr 07 18:51:49 EDT 2009:TSerial[22].Transmit:TN Tue Apr 07 18:51:49 EDT 2009:TSerial[22].Transmit:RV entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 ...REPEATS FOREVER? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090407/f26e5752/attachment.html From tjarvi at qbang.org Tue Apr 7 18:31:23 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 7 Apr 2009 18:31:23 -0600 (MDT) Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: <49D546F8.20807@gatworks.com> <49D693BA.8060909@gatworks.com> Message-ID: On Tue, 7 Apr 2009, Bill Johnson wrote: > I have traced the hang down to a call to tcdrain(fd) in SerialImp.c:drain() > running and rebuilt under Netbeans on the target machine with debug messages > on. That puts it into the system code, so I'm not sure how to proceed. I > guess I could debug into the kernel source but I've not done that. I saw > some discussion about an IOCTL that sets/adjusts a timeout on tcdrain() but > that may have been for BSD. Maybe there is some new setup requirement or bug > introduced with this 2.6.18 kernel or a hardware difference. > Below is a message listing with some of the repeated parts removed. Maybe > you can see something noteworthy? > > JNI_OnLoad called. > WARNING:? RXTX Version mismatch > ??????? Jar version = RXTX-2.2pre2 > ??????? native lib Version = RXTX-2.2pre3 > entering RXTXCommDriver:getDeviceDirectory > entering RXTXPort:testRead > fhs_lock: creating lockfile:????? 29704 > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXPort:testRead > RXTX Warning:? Removing stale lock file. /var/lock/LCK..ttyUSB2 > fhs_lock: creating lockfile:????? 29704 > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXPort:testRead > RXTX Warning:? Removing stale lock file. /var/lock/LCK..ttyUSB1 > fhs_lock: creating lockfile:????? 29704 > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXPort:testRead > RXTX Warning:? Removing stale lock file. /var/lock/LCK..ttyUSB0 > fhs_lock: creating lockfile:????? 29704 > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXPort:testRead > fhs_lock: creating lockfile:????? 29704 > > ... REPEATS > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXPort:testRead > fhs_lock: creating lockfile:????? 29704 > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXCommDriver:getDeviceDirectory > entering RXTXPort:testRead > fhs_lock: creating lockfile:????? 29704 > > ...REPEATS > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXPort:testRead > fhs_lock: creating lockfile:????? 29704 > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXPort:Initialize > > > > RXTX WARNING:? This library was compiled to run with OS release 2.6.18 and > you are currently running OS release 2.6.18-92.1.6.el5.? In some cases this > can be a problem.? Try recompiling RXTX if you notice strange behavior.? If > you just compiled RXTX make sure /usr/include/linux is a symbolic link to > the include files that came with the kernel source and not an older copy. > > > press enter to continue > > leaving RXTXPort:Initialize > entering RXTXPort:open > fhs_lock: creating lockfile:????? 29704 > > open: locking worked for /dev/ttyUSB2 > open: fd returned is 9 > leaving RXTXPort:open > entering eventLoop > ? > has_line_status_register_acess: Port does not support TIOCSERGETLSR > ?driver_has_tiocgicount:? Port does not support TIOCGICOUNT events > init_threads: get eis > init_threads: set eis > init_threads:? stop > leaving RXTXPort:translate_speed > entering RXTXPort:nativeSetSerialPortParams > entering translate_date_bits > entering translate_stop_bits > leaving RXTXPort:translate_stop_bits > entering translate_parity > leaving translate_parity > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > ...REPEATS > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > leaving RXTXPort:nativeSetSerialPortParams > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > ...REPEATS > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > entering writeArray > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > writeArray() > leaving RXTXPort:writeArray > entering SerialImp.c:drain() > nativeDrain: trying tcdrain > RXTXPort:drain() returns: 0 > leaving RXTXPort:drain() > entering writeArray > writeArray() > leaving RXTXPort:writeArray > entering SerialImp.c:drain() > nativeDrain: trying tcdrain > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > Tue Apr 07 18:51:49 EDT 2009:TSerial[22]:Using Port:/dev/ttyUSB2 > Tue Apr 07 18:51:49 EDT 2009:TSerial[22].Transmit:TN > > Tue Apr 07 18:51:49 EDT 2009:TSerial[22].Transmit:RV > > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > ...REPEATS FOREVER? > > > Hi Bill ugh. The tiocmget... is the eventLoop checking for events. It sits with select() but has a timeout value to keep it spinning at a trivial rate. tcdrain() is the suspect. I don't see anything in the code that looks like a problem. If flow control is not enabled, I don't see a reason for it not to return. Given that this is USB, perhaps a message from the device got lost. Onboard UARTs would have a status register change when output buffer is empty. USB needs to communicate the event as an HID device which may be the source of the error. Dropping back to onboard UARTs eliminates that portion of the mix. What vendor/chipset is the USB dongle? I understand code has been pushed upon the linux serial devices for new for things like acpi. There very well could be a bug introduced. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Apr 7 18:38:22 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 7 Apr 2009 18:38:22 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49DB4212.40807@bbs.darktech.org> References: <49DB4212.40807@bbs.darktech.org> Message-ID: On Tue, 7 Apr 2009, cowwoc wrote: >> just two minor details, first about the errno change, I though >> >> #include >> extern int errno; >> >> is correct (POSIX.1) - why this change? > > If you compile this under Visual Studio 2008 you will get warnings that > the errno type being imported is different from the type being exported. > The definition I pasted is the one being exported. Perhaps we should use > #ifdef WIN32 for this? > Hi Gili, Perhaps a workaround for _MSVC is in order. GNU compilers for windows won't complain. If it's a question of MSVC or POSIX being right, the library favors the standard as a stated goal. I'm not sure what MSVC is using errno for but it should not be using it except with POSIX extensions. Perhaps #undef is enough to get rid of the warning and (maybe) has no ill consequences. Newer windows have POSIX extensions that may show how Microsoft solved the problem. It can probably fester. -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Tue Apr 7 19:54:06 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Tue, 07 Apr 2009 21:54:06 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: References: <49DB4212.40807@bbs.darktech.org> Message-ID: <49DC03BE.5010203@bbs.darktech.org> Trent Jarvi wrote: > I'm not sure what MSVC is using errno for but it should not be using it > except with POSIX extensions. Perhaps #undef is enough to get rid of > the warning and (maybe) has no ill consequences. Newer windows have > POSIX extensions that may show how Microsoft solved the problem. > > It can probably fester. What does "newer windows" refer to in this case? I was compiling using Visual Studio 2008 sp1 under Windows Vista. Both are cutting edge technologies as far as official releases go. I think you're best suited to judge whether this warning is a big deal or not so I think you should see it for yourself. Please try firing up Visual Studio 2008 (express?) against the project I sent you. Gili From Steffen.DETTMER at ingenico.com Wed Apr 8 05:50:42 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 8 Apr 2009 13:50:42 +0200 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49DC03BE.5010203@bbs.darktech.org> References: <49DB4212.40807@bbs.darktech.org> <49DC03BE.5010203@bbs.darktech.org> Message-ID: <20090408115042.GC5090@elberon.bln.de.ingenico.com> * cowwoc wrote on Tue, Apr 07, 2009 at 21:54 -0400: > Trent Jarvi wrote: > > I'm not sure what MSVC is using errno for but it should not be using it > > except with POSIX extensions. Perhaps #undef is enough to get rid of > > the warning and (maybe) has no ill consequences. Newer windows have > > POSIX extensions that may show how Microsoft solved the problem. I think here best is simply to omit this old^Wclassic `extern int errno;' line completely. I think standards just say something like `implementations may support the declaration extern int errno;'. About POSIX extensions I think in general it should be considered that althrough many things are available, even with MS Visual C++, the Microsoft tools lead developers to write non-portable code (and personally I think this is intentional). For example, they call the official ISO-C function `strerror' deprecated (!) and twaddle about some security enhancements (without even beeing specific). Someone could, because of this, lead to use the MS specific, unportable `strerror_s' instead. Even better, at _strerror_s they tell, for `ANSI compatiblity someone should use strerror_s'. Of course a program using [_]strerror_s won't be ANSI-C compliant. Do they mean strerror_r? _strerror_s has the same parameters - but of course in different order - to make porting a pain... SCNR. > What does "newer windows" refer to in this case? I was compiling using > Visual Studio 2008 sp1 under Windows Vista. Both are cutting edge > technologies as far as official releases go. `cutting edge technologies' yeah post-standard, portability-cutting technologies smoothing the way to MS world domination; own post-ANSI-C programming languages help (maybe to increase the share holder value)... SCNR. > I think you're best suited to judge whether this warning is a big deal > or not so I think you should see it for yourself. Please try firing up > Visual Studio 2008 (express?) against the project I sent you. yeah, getting the CL.EXE of 2008 running in a normal command line environment (without its special `C++ Shell') is a bit tricky - but possible. ;) oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From cowwoc at bbs.darktech.org Wed Apr 1 22:05:13 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Thu, 02 Apr 2009 00:05:13 -0400 Subject: [Rxtx] Windows 64-bit support? Message-ID: <49D43979.4050702@bbs.darktech.org> Hi, I'd like to run RXTX under the Windows 64-bit JVM. Are there plans to release an official 64-bit version anytime soon? Gili From bill7007 at gmail.com Thu Apr 2 16:01:17 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Thu, 2 Apr 2009 18:01:17 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel Message-ID: Hi, I have an rxtx serial application that used to work reliably until I had to move it to newer hardware and kernel. Now, the application sometimes hangs near first port use. When it does hang, it can be released by starting a second copy of the application which is locked out of the ports but does release the first process. Upgraded from rxtx-2.1-7-r2 to rxtx-2.2pre2 but still hangs. Tried to rebuild on the target machine and ran into the 'UTS_RELEASE' undeclared problem so holding on that approach. Recompiled OK on a 2.6.9-42.0.3.ELsmp system. Debug messages were turned on using: "./configure --enable-DEBUG" and modified RXTXPort.java with: "debug = true;" "z = new Zystem(Zystem.PRINT_MODE);" Below is capture of the application with debugging enabled. It show the application hang point, and the second application's printout at the release point. (pre3 is the locally modified version of pre2) Any suggestions on how to pin this down further? Thanks, +BillJ $ java -version java version "1.5.0_06" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05) Java HotSpot(TM) Client VM (build 1.5.0_06-b05, mixed mode, sharing) $ uname -a Linux qms4 2.6.18-92.1.6.el5 #1 SMP Wed Jun 25 13:49:24 EDT 2008 i686 i686 i386 GNU/Linux ***CAPTURE: [qms at qms4 ~]$ ./qms/ScriptFiles/startup.sh Thu Apr 02 13:35:45 EDT 2009:Setting Log File to:/home/qms/qms/QMS.log Thu Apr 02 13:35:45 EDT 2009:TSettings.HandleIni:ReUsing Ini file:/home/qms/qms/qms.properties WARNING: RXTX Version mismatch Jar version = RXTX-2.2pre2 native lib Version = RXTX-2.2pre3 fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB2 fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB1 fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB0 fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile RXTXPort {} RXTX WARNING: This library was compiled to run with OS release 2.4.20 and you are currently running OS release 2.6.18-92.1.6.el5. In some cases this can be a problem. Try recompiling RXTX if you notice strange behavior. If you just compiled RXTX make sure /usr/include/linux is a symbolic link to the include files that came with the kernel source and not an older copy. press enter to continue RXTXPort:RXTXPort(/dev/ttyUSB2) called fhs_lock: creating lockfile: 10127 open: locking worked for /dev/ttyUSB2 open: fd returned is 8 RXTXPort:MontitorThread:MonitorThread() RXTXPort:MontitorThread:run() has_line_status_register_acess: Port does not support TIOCSERGETLSR init_threads: get eis init_threads: set eis init_threads: stop RXTXPort:RXTXPort(/dev/ttyUSB2) returns with fd = 8 RXTXPort:setSerialPortParams(38400 8 1 0) called RXTXPort:setSerialPortParams(38400 8 1 0) returning RXTXPort:getInputStream() called and returning Thu Apr 02 13:36:02 EDT 2009:TSerial[22]:Using Port:/dev/ttyUSB2 RXTXPort:getOutputStream() called and returning Thu Apr 02 13:36:02 EDT 2009:TSerial[22].Transmit:TN Entering RXTXPort:SerialOutputStream:write(4) writeArray() Leaving RXTXPort:SerialOutputStream:write(4) RXTXPort:SerialOutputStream:flush() enter RXTXPort:SerialOutputStream:flush() leave Thu Apr 02 13:36:02 EDT 2009:TSerial[22].Transmit:RV Entering RXTXPort:SerialOutputStream:write(4) writeArray() Leaving RXTXPort:SerialOutputStream:write(4) RXTXPort:SerialOutputStream:flush() enter RXTXPort:SerialInputStream:read(8192 0 8192) called ***FIRST PROCESS HANGS HERE ***THEN PROCEEDS AFTER SECOND PROCESS STARTS RXTXPort:SerialOutputStream:flush() leave Thu Apr 02 13:41:29 EDT 2009:TSerial[22].Transmit:IH9 Entering RXTXPort:SerialOutputStream:write(5) writeArray() Leaving RXTXPort:SerialOutputStream:write(5) RXTXPort:SerialOutputStream:flush() enter RXTXPort:SerialOutputStream:flush() leave Thu Apr 02 13:41:29 EDT 2009:TSerial[22].Transmit:IL11 ***END CAPTURE ***CAPTURE SECOND PROCESS FAILS OPEN [qms at qms4 ~]$ ./qms/ScriptFiles/startup.sh Thu Apr 02 13:41:27 EDT 2009:Setting Log File to:/home/qms/qms/QMS.log Thu Apr 02 13:41:27 EDT 2009:TSettings.HandleIni:ReUsing Ini file:/home/qms/qms/qms.properties WARNING: RXTX Version mismatch Jar version = RXTX-2.2pre2 native lib Version = RXTX-2.2pre3 fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB2: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB1: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB0: File exists fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB2: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB1: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB0: File exists fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile Thu Apr 02 13:41:30 EDT 2009:TIOBoard: java.io.IOException: java.io.IOException: TSerial[22]: Open Failed ***END CAPTURE -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090402/c66f8d70/attachment-0007.html From netbeans at gatworks.com Thu Apr 2 17:15:04 2009 From: netbeans at gatworks.com (U. George) Date: Thu, 02 Apr 2009 19:15:04 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: Message-ID: <49D546F8.20807@gatworks.com> > "z = new Zystem(Zystem.PRINT_MODE);" > Below is capture of the application with debugging enabled. It show > the application hang point, and the second application's printout at the > release point. (pre3 is the locally modified version of pre2) > Any suggestions on how to pin this down further? > Thanks, > +BillJ When perceived runability is hung, try a ^\ ( control \) on console. This gets the JVM to dump the stacks of all the java threads. If you know the thread that is stuck, then u can see what java statement its stuck at. From tjarvi at qbang.org Thu Apr 2 19:25:17 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 2 Apr 2009 19:25:17 -0600 (MDT) Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: <49D546F8.20807@gatworks.com> References: <49D546F8.20807@gatworks.com> Message-ID: On Thu, 2 Apr 2009, U. George wrote: >> "z = new Zystem(Zystem.PRINT_MODE);" >> Below is capture of the application with debugging enabled. It show >> the application hang point, and the second application's printout at the >> release point. (pre3 is the locally modified version of pre2) >> Any suggestions on how to pin this down further? >> Thanks, >> +BillJ > > When perceived runability is hung, try a ^\ ( control \) on console. > This gets the JVM to dump the stacks of all the java threads. > If you know the thread that is stuck, then u can see what java statement > its stuck at. I've also noticed some linux systems hanging with open/read/write and saw kacpid storms. I need to look at it more but did observe kacpid consuming a core and not returning to a normal state for a significant period of time. It was easy to observe from top sorted by CPU usage. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Apr 2 19:26:18 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 2 Apr 2009 19:26:18 -0600 (MDT) Subject: [Rxtx] Windows 64-bit support? In-Reply-To: <49D43979.4050702@bbs.darktech.org> References: <49D43979.4050702@bbs.darktech.org> Message-ID: On Thu, 2 Apr 2009, cowwoc wrote: > Hi, > > I'd like to run RXTX under the Windows 64-bit JVM. Are there plans > to release an official 64-bit version anytime soon? > It is in the prerelease and will be in the final release. I'm pushing it through as fast as I can in my free time. -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Thu Apr 2 22:57:34 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Fri, 03 Apr 2009 00:57:34 -0400 Subject: [Rxtx] Missing documentation In-Reply-To: References: <49D43979.4050702@bbs.darktech.org> Message-ID: <49D5973E.4050400@bbs.darktech.org> Hi, I noticed that RXTX 2.1 drops javax.comm support in favor of gnu.io. I have one major problem with this: the gui.io.* documentation is very poor. Many classes and methods have no Javadoc at all which makes them difficult to use. Please fix this for the final release. Thank you, Gili From alex.sas at freemail.hu Fri Apr 3 01:36:54 2009 From: alex.sas at freemail.hu (Sas Alex) Date: Fri, 3 Apr 2009 09:36:54 +0200 (CEST) Subject: [Rxtx] Serial port false reads Message-ID: Hi all, On Windows XP, using rxtx-2.1-7-r2 I have a program communicating on a serial line like the following (excerpt): { os.write(command); os.flush(); // Thread.sleep(period); // read response while(is.available() > 0) { is.read() } } If there is a sleep between the os.flush and the reading cycle the correct answer is received. Otherwise (sometimes) there are extra, erronous characters at the beginning of the answer, but the correct answer (according to the protocol) also arrives, afterwards. Is this a normal behaviour, one should wait before the read? If yes, is there a way to determine the minimum amount of time to wait for? Serial port params are: 9600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE. Thank you in advance, Alex ________________________________________________________ El?foglal?si akci? meghosszabb?tva! Korfui ?d?l?s m?r 56.910 Ft-t?l. http://www.budavartours.hu/gorogorszag/?utm_campaign=origo&utm_source=freemail_kimeno_090403&utm_medium=ct&utm_content=korfu_elofoglalasi_akcio#reg_Korfu -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090403/8f3650ea/attachment-0007.html From bill7007 at gmail.com Fri Apr 3 16:15:30 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Fri, 3 Apr 2009 18:15:30 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: <49D546F8.20807@gatworks.com> Message-ID: > When perceived runability is hung, try a ^\ ( control \) on console. >> This gets the JVM to dump the stacks of all the java threads. > > Good idea... A thread dump is below, it looks like only some system threads are in wait state which is probably normal. The "main" thread is stopped writing the first data out the serial port which should complete but its has stopped at: at gnu.io.RXTXPort.nativeDrain(Native Method) It show its state as runnable though. There is another thread, "SerialReader_22", that is waiting to read any data on the same port. I'll bring the app up under Netbeans debugger next. >> > I've also noticed some linux systems hanging with open/read/write and saw > kacpid storms. No CPU use going when it hangs, acts like a deadlock. THREAD DUMP AT HANG: Entering RXTXPort:SerialOutputStream:write(4) writeArray() Leaving RXTXPort:SerialOutputStream:write(4) RXTXPort:SerialOutputStream:flush() enter RXTXPort:SerialInputStream:read(8192 0 8192) called Full thread dump Java HotSpot(TM) Client VM (1.5.0_06-b05 mixed mode, sharing): "SerialReader_22" daemon prio=1 tid=0x087abf38 nid=0x3c8b runnable [0xb1a43000..0xb1a43f30] at gnu.io.RXTXPort.readArray(Native Method) at gnu.io.RXTXPort$SerialInputStream.read(RXTXPort.java:1454) - locked <0x88ca55b8> (a gnu.io.RXTXPort$SerialInputStream) at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:411) at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) - locked <0x88cab378> (a java.io.InputStreamReader) at java.io.InputStreamReader.read(InputStreamReader.java:167) at java.io.BufferedReader.fill(BufferedReader.java:136) at java.io.BufferedReader.readLine(BufferedReader.java:299) - locked <0x88cab378> (a java.io.InputStreamReader) at java.io.BufferedReader.readLine(BufferedReader.java:362) at qms.TSerialPort$SerialRead.run(TSerialPort.java:268) at java.lang.Thread.run(Thread.java:595) "Thread-1" prio=1 tid=0x08a43360 nid=0x3c8a runnable [0xb1ac4000..0xb1ac4db0] at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1641) "AWT-XAWT" daemon prio=1 tid=0x08acc848 nid=0x3c87 runnable [0xb1b45000..0xb1b45e30] at sun.awt.X11.XToolkit.waitForEvents(Native Method) at sun.awt.X11.XToolkit.run(XToolkit.java:463) at sun.awt.X11.XToolkit.run(XToolkit.java:438) at java.lang.Thread.run(Thread.java:595) "Java2D Disposer" daemon prio=1 tid=0x08ab9d30 nid=0x3c86 in Object.wait() [0xb1bc6000..0xb1bc70b0] at java.lang.Object.wait(Native Method) - waiting on <0x8917b110> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:116) - locked <0x8917b110> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:132) at sun.java2d.Disposer.run(Disposer.java:107) at java.lang.Thread.run(Thread.java:595) "Low Memory Detector" daemon prio=1 tid=0x087bea68 nid=0x3c84 runnable [0x00000000..0x00000000] "CompilerThread0" daemon prio=1 tid=0x087bd4c0 nid=0x3c83 waiting on condition [0x00000000..0xb23a7a18] "Signal Dispatcher" daemon prio=1 tid=0x087bc520 nid=0x3c82 runnable [0x00000000..0x00000000] "Finalizer" daemon prio=1 tid=0x087b5710 nid=0x3c81 in Object.wait() [0xb26a9000..0xb26a9f30] at java.lang.Object.wait(Native Method) - waiting on <0x8914a770> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:116) - locked <0x8914a770> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:132) at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159) "Reference Handler" daemon prio=1 tid=0x087b49c8 nid=0x3c80 in Object.wait() [0xb272a000..0xb272adb0] at java.lang.Object.wait(Native Method) - waiting on <0x8914a7f0> (a java.lang.ref.Reference$Lock) at java.lang.Object.wait(Object.java:474) at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116) - locked <0x8914a7f0> (a java.lang.ref.Reference$Lock) "main" prio=1 tid=0x08777b88 nid=0x3c7e runnable [0xbffa7000..0xbffa74f8] at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1248) at qms.TSerialPort.Transmit(TSerialPort.java:192) - locked <0x88c99a68> (a qms.TSerialPort) at qms.TIOBoard.GetIOBoardVersion(TIOBoard.java:168) at qms.TIOBoard.(TIOBoard.java:73) at qms.TQMS.(TQMS.java:47) at qms.MainForm.(MainForm.java:2076) at qms.MainForm.main(MainForm.java:2099) "VM Thread" prio=1 tid=0x087b1e20 nid=0x3c7f runnable "VM Periodic Task Thread" prio=1 tid=0x087bff50 nid=0x3c85 waiting on condition -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090403/20b7bca4/attachment-0006.html From Martin.Oberhuber at windriver.com Fri Apr 3 16:23:43 2009 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Sat, 4 Apr 2009 00:23:43 +0200 Subject: [Rxtx] Missing documentation In-Reply-To: <49D5973E.4050400@bbs.darktech.org> References: <49D43979.4050702@bbs.darktech.org> <49D5973E.4050400@bbs.darktech.org> Message-ID: <460801A4097E3D4CA04CC64EE648584809C8BD6F@ism-mail03.corp.ad.wrs.com> Hello Gili, The classes in the gnu.io namespace are designed to work exactly as their counterparts in the javax.comm namespace. Therefore, if you just take the javax.comm Javadocs that's what you want. Unfortunately I don't think we can just copy & paste the javax.comm Javadocs into RXTX due to license restrictions. I guess that's the main reason why RXTX is not (yet) Javadoc'd as extensively as it should be. Actually, writing Javadocs from scratch WITHOUT referencing the wording of the Sun Javadocs is not that easy. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of cowwoc > Sent: Freitag, 03. April 2009 06:58 > To: rxtx at qbang.org > Subject: [Rxtx] Missing documentation > > Hi, > > I noticed that RXTX 2.1 drops javax.comm support in favor > of gnu.io. > I have one major problem with this: the gui.io.* > documentation is very > poor. Many classes and methods have no Javadoc at all which > makes them > difficult to use. Please fix this for the final release. > > Thank you, > Gili > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Fri Apr 3 16:54:50 2009 From: netbeans at gatworks.com (U. George) Date: Fri, 03 Apr 2009 18:54:50 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: <49D546F8.20807@gatworks.com> Message-ID: <49D693BA.8060909@gatworks.com> I would have tried 2 or 3 "^\" . If things are stuck, then all will be at same 'java' instruction. If thread is moving, then one of the snapshots would be different. I *think* flushing/draining wont return until the kernel buffers to device have been accepted by device. Stuck/paused device? Bill Johnson wrote: > > > > > When perceived runability is hung, try a ^\ ( control \) on console. > This gets the JVM to dump the stacks of all the java threads. > > > Good idea... A thread dump is below, it looks like only some system > threads are in wait state which is prob From cowwoc at bbs.darktech.org Fri Apr 3 17:45:09 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Fri, 03 Apr 2009 19:45:09 -0400 Subject: [Rxtx] Missing documentation In-Reply-To: <460801A4097E3D4CA04CC64EE648584809C8BD6F@ism-mail03.corp.ad.wrs.com> References: <49D43979.4050702@bbs.darktech.org> <49D5973E.4050400@bbs.darktech.org> <460801A4097E3D4CA04CC64EE648584809C8BD6F@ism-mail03.corp.ad.wrs.com> Message-ID: <49D69F85.3030804@bbs.darktech.org> You could always send Sun a formal email and ask for permission to copy their Javadoc. I doubt they would give you problems. Gili Oberhuber, Martin wrote: > Hello Gili, > > The classes in the gnu.io namespace are designed to work exactly > as their counterparts in the javax.comm namespace. Therefore, > if you just take the javax.comm Javadocs that's what you want. > > Unfortunately I don't think we can just copy & paste the > javax.comm Javadocs into RXTX due to license restrictions. > > I guess that's the main reason why RXTX is not (yet) Javadoc'd > as extensively as it should be. Actually, writing Javadocs > from scratch WITHOUT referencing the wording of the Sun > Javadocs is not that easy. > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] >> On Behalf Of cowwoc >> Sent: Freitag, 03. April 2009 06:58 >> To: rxtx at qbang.org >> Subject: [Rxtx] Missing documentation >> >> Hi, >> >> I noticed that RXTX 2.1 drops javax.comm support in favor >> of gnu.io. >> I have one major problem with this: the gui.io.* >> documentation is very >> poor. Many classes and methods have no Javadoc at all which >> makes them >> difficult to use. Please fix this for the final release. >> >> Thank you, >> Gili >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> From cowwoc at bbs.darktech.org Sat Apr 4 15:13:38 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sat, 04 Apr 2009 17:13:38 -0400 Subject: [Rxtx] Java5 support Message-ID: <49D7CD82.1040904@bbs.darktech.org> Now that you dropped javax.comm support, how about improving the API by replacing Enumation by Iterator, int by enum, and using Generics? It would improve the usability of the API. Gili From cowwoc at bbs.darktech.org Sat Apr 4 16:12:13 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sat, 04 Apr 2009 18:12:13 -0400 Subject: [Rxtx] RXTX Version mismatch in 2.2pre2 Message-ID: <49D7DB3D.5040008@bbs.darktech.org> When using RXTX-2.2pre2 I always get the following message: WARNING: RXTX Version mismatch Jar version = RXTX-2.2pre1 native lib Version = RXTX-2.2pre2 I have double checked that I am using the correct Jar file. Is this a known bug in pre2? Gili From tjarvi at qbang.org Sat Apr 4 16:48:53 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Apr 2009 16:48:53 -0600 (MDT) Subject: [Rxtx] RXTX Version mismatch in 2.2pre2 In-Reply-To: <49D7DB3D.5040008@bbs.darktech.org> References: <49D7DB3D.5040008@bbs.darktech.org> Message-ID: > When using RXTX-2.2pre2 I always get the following message: > > WARNING: RXTX Version mismatch > Jar version = RXTX-2.2pre1 > native lib Version = RXTX-2.2pre2 > Yep. You should still be able to test it. -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Sat Apr 4 16:50:43 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sat, 04 Apr 2009 18:50:43 -0400 Subject: [Rxtx] RXTX Version mismatch in 2.2pre2 In-Reply-To: References: <49D7DB3D.5040008@bbs.darktech.org> Message-ID: <49D7E443.9070404@bbs.darktech.org> In other words this is a known bug that will be fixed in the final version? Gili Trent Jarvi wrote: > > >> When using RXTX-2.2pre2 I always get the following message: >> >> WARNING: RXTX Version mismatch >> Jar version = RXTX-2.2pre1 >> native lib Version = RXTX-2.2pre2 >> > > Yep. > > You should still be able to test it. > > -- > Trent Jarvi > tjarvi at qbang.org From cowwoc at bbs.darktech.org Sat Apr 4 16:57:34 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sat, 04 Apr 2009 18:57:34 -0400 Subject: [Rxtx] IOException: Underlying input stream returned zero bytes Message-ID: <49D7E5DE.2050405@bbs.darktech.org> Hi, There seems to be a bug in RXTX 2.2pre2's handling of InputStream timeouts. If you open a serial port without ever invoking enableReceiveTimeout() then invoking InputStream.read() will always return 0 bytes right away. If you wrap the InputStream and invoke BufferedReader.readline() you will get the following exception: java.io.IOException: Underlying input stream returned zero bytes at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:268) [na:1.6.0_14-ea] at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:306) [na:1.6.0_14-ea] at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:158) [na:1.6.0_14-ea] at java.io.InputStreamReader.read(InputStreamReader.java:167) [na:1.6.0_14-ea] at java.io.BufferedReader.fill(BufferedReader.java:136) [na:1.6.0_14-ea] at java.io.BufferedReader.readLine(BufferedReader.java:299) [na:1.6.0_14-ea] at java.io.BufferedReader.readLine(BufferedReader.java:362) [na:1.6.0_14-ea] [snip] If you enable a timeout, the exception will only occur after the timeout expires. In short, it looks like RXTX is using a default timeout of zero (I am expecting it to block forever). It looks like other people have run into this as well: http://forums.sun.com/thread.jspa?threadID=5165346&start=10&tstart=0 Please confirm whether this is a known bug. Thank you, Gili From tjarvi at qbang.org Sat Apr 4 17:27:19 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Apr 2009 17:27:19 -0600 (MDT) Subject: [Rxtx] IOException: Underlying input stream returned zero bytes In-Reply-To: <49D7E5DE.2050405@bbs.darktech.org> References: <49D7E5DE.2050405@bbs.darktech.org> Message-ID: On Sat, 4 Apr 2009, cowwoc wrote: > Hi, > > There seems to be a bug in RXTX 2.2pre2's handling of InputStream > timeouts. If you open a serial port without ever invoking > enableReceiveTimeout() then invoking InputStream.read() will always > return 0 bytes right away. If you wrap the InputStream and invoke > BufferedReader.readline() you will get the following exception: > > java.io.IOException: Underlying input stream returned zero bytes > at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:268) > [na:1.6.0_14-ea] > at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:306) > [na:1.6.0_14-ea] > at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:158) > [na:1.6.0_14-ea] > at java.io.InputStreamReader.read(InputStreamReader.java:167) > [na:1.6.0_14-ea] > at java.io.BufferedReader.fill(BufferedReader.java:136) > [na:1.6.0_14-ea] > at java.io.BufferedReader.readLine(BufferedReader.java:299) > [na:1.6.0_14-ea] > at java.io.BufferedReader.readLine(BufferedReader.java:362) > [na:1.6.0_14-ea] > [snip] > > If you enable a timeout, the exception will only occur after the > timeout expires. In short, it looks like RXTX is using a default timeout > of zero (I am expecting it to block forever). It looks like other people > have run into this as well: > http://forums.sun.com/thread.jspa?threadID=5165346&start=10&tstart=0 > > Please confirm whether this is a known bug. > Hi Gili I've known about it but was not sure if it was a bug or not. It looks like we can treat it as a bug if nio is throwing an exception. Timeout and Thresholds are well documented in javax.comm but I didn't recall seeing defaults. For that reason, I've encouraged people to set the threshold and timeout to what they expect. Another note about InputStream.read(void): I noticed that I don't use that function at all while looking at code coverage results. Keep your eye out for additional issues. -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Sat Apr 4 19:03:29 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sat, 04 Apr 2009 21:03:29 -0400 Subject: [Rxtx] IOException: Underlying input stream returned zero bytes In-Reply-To: References: <49D7E5DE.2050405@bbs.darktech.org> Message-ID: <49D80361.7020801@bbs.darktech.org> Trent Jarvi wrote: > For that reason, I've encouraged people to set the threshold and timeout > to what they expect. It doesn't help. There doesn't seem to be a way to disable the timeout, even if you invoke disableReceiveTimeout() explicitly. Let me know when you put in a fix and I will test it. Thanks, Gili From cowwoc at bbs.darktech.org Sat Apr 4 23:27:25 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 01:27:25 -0400 Subject: [Rxtx] Crash in termios.c:892 Message-ID: <49D8413D.7040105@bbs.darktech.org> I can reproduce a crash in RXTX 2.2 pre2 100% of the time using my application code, but I can't seem to bring it down to a minimal testcase. Here is what I see: - thread begins running - open com1 - close com1 - open com5 - leave com5 open - thread shuts down - repeat the same process in a new thread - crash occurs when trying to open com1. Crash disappears if I close() com5 in the previous thread. The output window contains the following: # # A fatal error has been detected by the Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x05475cf6, pid=6064, tid=5436 # # JRE version: 6.0_14-b04 # Java VM: Java HotSpot(TM) Client VM (14.0-b13 mixed mode, sharing windows-x86 ) # Problematic frame: # C [rxtxSerial.dll+0x5cf6] # # An error report file with more information is saved as: # C:\Users\Gili\Documents\foobar\source\hs_err_pid6064.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp Error 0x5 at ..\src\termios.c(892): Access is denied. # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # Please let me know if the crash dump is enough to track down this bug. Thank you, Gili -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: hs_err_pid6064.log Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20090405/7133a1ce/attachment-0003.pl From cowwoc at bbs.darktech.org Sun Apr 5 00:24:19 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 02:24:19 -0400 Subject: [Rxtx] SerialPort.getName() is wrong Message-ID: <49D84E93.7050606@bbs.darktech.org> Sorry for all these emails but I keep on running into more issues. Here is what I noticed: - CommPortIdentifier.getPortIdentifier("COM5") returns a CommPortIdentifier where getName() == "COM5" - If, however, you invoke CommPortIdentifier.open() you get back a SerialPort where SerialPort.getName() is "//./COM5" I am expecting the name to remain consistent. "//./COM5" looks like an implementation detail and (as far as I can tell) it can't be used as an argument for any API method so it is somewhat useless. If getName() were to return "COM5" I could at least use it to get back the original CommPortIdentifier or compare against "known names" such as "COMx" or "LPTx". What do you think? Gili From tjarvi at qbang.org Sun Apr 5 10:18:42 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Apr 2009 10:18:42 -0600 (MDT) Subject: [Rxtx] SerialPort.getName() is wrong In-Reply-To: <49D84E93.7050606@bbs.darktech.org> References: <49D84E93.7050606@bbs.darktech.org> Message-ID: On Sun, 5 Apr 2009, cowwoc wrote: > > Sorry for all these emails but I keep on running into more issues. > Here is what I noticed: > > - CommPortIdentifier.getPortIdentifier("COM5") returns a > CommPortIdentifier where getName() == "COM5" > - If, however, you invoke CommPortIdentifier.open() you get back a > SerialPort where SerialPort.getName() is "//./COM5" > > I am expecting the name to remain consistent. "//./COM5" looks like > an implementation detail and (as far as I can tell) it can't be used as > an argument for any API method so it is somewhat useless. If getName() > were to return "COM5" I could at least use it to get back the original > CommPortIdentifier or compare against "known names" such as "COMx" or > "LPTx". What do you think? > Sure. If it itches enough you should be able to fix this in RXTXCommDriver.java. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Apr 5 10:27:58 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Apr 2009 10:27:58 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D8413D.7040105@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> Message-ID: On Sun, 5 Apr 2009, cowwoc wrote: > > I can reproduce a crash in RXTX 2.2 pre2 100% of the time using my > application code, but I can't seem to bring it down to a minimal testcase. > Here is what I see: > > - thread begins running > - open com1 > - close com1 > - open com5 > - leave com5 open > - thread shuts down > - repeat the same process in a new thread > - crash occurs when trying to open com1. Crash disappears if I close() com5 > in the previous thread. > > The output window contains the following: > > # > # A fatal error has been detected by the Java Runtime Environment: > # > # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x05475cf6, pid=6064, > tid=5436 > # > # JRE version: 6.0_14-b04 > # Java VM: Java HotSpot(TM) Client VM (14.0-b13 mixed mode, sharing > windows-x86 ) > # Problematic frame: > # C [rxtxSerial.dll+0x5cf6] > # > # An error report file with more information is saved as: > # C:\Users\Gili\Documents\foobar\source\hs_err_pid6064.log > # > # If you would like to submit a bug report, please visit: > # http://java.sun.com/webapps/bugreport/crash.jsp > Error 0x5 at ..\src\termios.c(892): Access is denied. > > > # The crash happened outside the Java Virtual Machine in native code. > # See problematic frame for where to report the bug. > # > > Please let me know if the crash dump is enough to track down this bug. > Hi Gili, You are responsible for cleaning up the serial ports when using threads. That said, if the thread did shut down, finalize should have been called if you are not passing the object around. See RXTXPort.java. protected void finalize() { if (debug) z.reportln( "RXTXPort:finalize()"); if( fd > 0 ) { if (debug) z.reportln( "RXTXPort:calling close()"); close(); } z.finalize(); } The exception is interesting. This is on Vista? Usually it just gives an open error when another process has the port. -- Trent Jarvi tjarvi at mathworks.com From cowwoc at bbs.darktech.org Sun Apr 5 10:35:55 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 12:35:55 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: References: <49D8413D.7040105@bbs.darktech.org> Message-ID: <49D8DDEB.5010908@bbs.darktech.org> Trent Jarvi wrote: > You are responsible for cleaning up the serial ports when using threads. > That said, if the thread did shut down, finalize should have been called > if you are not passing the object around. See RXTXPort.java. > > protected void finalize() > { > if (debug) > z.reportln( "RXTXPort:finalize()"); > if( fd > 0 ) > { > if (debug) > z.reportln( "RXTXPort:calling close()"); > close(); > } > z.finalize(); > } Two points: 1) One should never rely on finalizers because they may never run. 2) RXTX shouldn't cause the entire JVM to crash if I misuse the API. The native code should recover more gracefully. > The exception is interesting. This is on Vista? Usually it just gives > an open error when another process has the port. Yes, this is on Vista 64-bit. I'd really like to see this bug fixed. Is this code compilable under Visual Studio? If so, I can debug the problem on my end and send you a patch. Thanks, Gili From cowwoc at bbs.darktech.org Sun Apr 5 10:36:20 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 12:36:20 -0400 Subject: [Rxtx] SerialPort.getName() is wrong In-Reply-To: References: <49D84E93.7050606@bbs.darktech.org> Message-ID: <49D8DE04.6030306@bbs.darktech.org> Trent Jarvi wrote: >> I am expecting the name to remain consistent. "//./COM5" looks like >> an implementation detail and (as far as I can tell) it can't be used as >> an argument for any API method so it is somewhat useless. If getName() >> were to return "COM5" I could at least use it to get back the original >> CommPortIdentifier or compare against "known names" such as "COMx" or >> "LPTx". What do you think? >> > > Sure. > > If it itches enough you should be able to fix this in RXTXCommDriver.java. I'm not sure I understand. Are you saying that if I submit a patch you will commit it? Gili From tjarvi at qbang.org Sun Apr 5 10:46:23 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Apr 2009 10:46:23 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D8DDEB.5010908@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> Message-ID: On Sun, 5 Apr 2009, cowwoc wrote: > Trent Jarvi wrote: >> You are responsible for cleaning up the serial ports when using threads. >> That said, if the thread did shut down, finalize should have been called if >> you are not passing the object around. See RXTXPort.java. >> >> protected void finalize() >> { >> if (debug) >> z.reportln( "RXTXPort:finalize()"); >> if( fd > 0 ) >> { >> if (debug) >> z.reportln( "RXTXPort:calling close()"); >> close(); >> } >> z.finalize(); >> } > > Two points: > > 1) One should never rely on finalizers because they may never run. > 2) RXTX shouldn't cause the entire JVM to crash if I misuse the API. The > native code should recover more gracefully. > >> The exception is interesting. This is on Vista? Usually it just gives an >> open error when another process has the port. > > Yes, this is on Vista 64-bit. I'd really like to see this bug fixed. > Is this code compilable under Visual Studio? If so, I can debug the problem > on my end and send you a patch. > It will compile with the msvc cl.exe and nmake. See Makefile.msvc in the top level directory. You will need to adjust the JAVA_HOME variable. Also use the MSVC command prompt for x86_64 so cl and nmake are on your path. All the best, -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Apr 5 10:49:10 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Apr 2009 10:49:10 -0600 (MDT) Subject: [Rxtx] SerialPort.getName() is wrong In-Reply-To: <49D8DE04.6030306@bbs.darktech.org> References: <49D84E93.7050606@bbs.darktech.org> <49D8DE04.6030306@bbs.darktech.org> Message-ID: On Sun, 5 Apr 2009, cowwoc wrote: > Trent Jarvi wrote: >>> I am expecting the name to remain consistent. "//./COM5" looks like >>> an implementation detail and (as far as I can tell) it can't be used as >>> an argument for any API method so it is somewhat useless. If getName() >>> were to return "COM5" I could at least use it to get back the original >>> CommPortIdentifier or compare against "known names" such as "COMx" or >>> "LPTx". What do you think? >>> >> >> Sure. >> >> If it itches enough you should be able to fix this in RXTXCommDriver.java. > > I'm not sure I understand. Are you saying that if I submit a patch > you will commit it? > Hi Gili, Post a patch here and if nobody complains, we will commit it and give you credit. Yep. Other issues like changing the API to use java5 that may break existing apps are likely to run into objections but bug fixes usually get fixed just as you mention. -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Sun Apr 5 10:55:07 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 12:55:07 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> Message-ID: <49D8E26B.2040705@bbs.darktech.org> Trent Jarvi wrote: > It will compile with the msvc cl.exe and nmake. See Makefile.msvc in > the top level directory. You will need to adjust the JAVA_HOME > variable. Also use the MSVC command prompt for x86_64 so cl and nmake > are on your path. This is very odd. The CVS version of the code does not contain this file. Do you keep the latest code somewhere else? Gili From cowwoc at bbs.darktech.org Sun Apr 5 11:01:58 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 13:01:58 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D8E26B.2040705@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> Message-ID: <49D8E406.10708@bbs.darktech.org> cowwoc wrote: > Trent Jarvi wrote: >> It will compile with the msvc cl.exe and nmake. See Makefile.msvc in >> the top level directory. You will need to adjust the JAVA_HOME >> variable. Also use the MSVC command prompt for x86_64 so cl and nmake >> are on your path. > > This is very odd. The CVS version of the code does not contain this > file. Do you keep the latest code somewhere else? Okay I figured it out. CVS head is out of date, the "commapi-0-0-1" revision contains the correct files. Gili From tjarvi at qbang.org Sun Apr 5 11:05:43 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Apr 2009 11:05:43 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D8E26B.2040705@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> Message-ID: CVS HEAD is currently the rxtx 2.0 code. A branch was created long ago for 'experimental' gnu.io work. It just happens that the branch is what everyone uses now. checkout -r commapi-0-0-1 rxtx-devel will get the branch On Sun, 5 Apr 2009, cowwoc wrote: > Trent Jarvi wrote: >> It will compile with the msvc cl.exe and nmake. See Makefile.msvc in the >> top level directory. You will need to adjust the JAVA_HOME variable. Also >> use the MSVC command prompt for x86_64 so cl and nmake are on your path. > > This is very odd. The CVS version of the code does not contain this > file. Do you keep the latest code somewhere else? > > Gili > From cowwoc at bbs.darktech.org Sun Apr 5 14:50:47 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 16:50:47 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> Message-ID: <49D919A7.1070806@bbs.darktech.org> Okay, I tracked down the crash. It's being caused by YACK() using a 80-character buffer. The error message is longer than 80 characters, so _snprintf_s() crashes to avoid a buffer overflow. Please apply the attached patch and add the zipped up Visual Studio project directory. It's not perfect yet but it's a good start. Gili Trent Jarvi wrote: > > CVS HEAD is currently the rxtx 2.0 code. A branch was created long > ago for 'experimental' gnu.io work. It just happens that the branch > is what everyone uses now. > > checkout -r commapi-0-0-1 rxtx-devel > > will get the branch > > On Sun, 5 Apr 2009, cowwoc wrote: > >> Trent Jarvi wrote: >>> It will compile with the msvc cl.exe and nmake. See Makefile.msvc >>> in the top level directory. You will need to adjust the JAVA_HOME >>> variable. Also use the MSVC command prompt for x86_64 so cl and >>> nmake are on your path. >> >> This is very odd. The CVS version of the code does not contain >> this file. Do you keep the latest code somewhere else? >> >> Gili >> -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx-devel.patch Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20090405/d9b82962/attachment-0002.pl -------------- next part -------------- A non-text attachment was scrubbed... Name: Win32.zip Type: application/octet-stream Size: 17764 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20090405/d9b82962/attachment-0004.obj From cowwoc at bbs.darktech.org Sun Apr 5 15:22:01 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 17:22:01 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D919A7.1070806@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> <49D919A7.1070806@bbs.darktech.org> Message-ID: <49D920F9.6080702@bbs.darktech.org> My mistake. The problem in YACK is real, but it isn't the real cause of the crash. The crash is caused by termios.c line 1099: index->prev->next = port; because in my case "index->prev==0". I think the bug is that the code assumes that index will contain a minimum of two entries if we're inserting a previously closed fd. In my case, it only contains one. I'm not sure why you have this code branch (as opposed to appending to the end of index). Please take a look. Thanks, Gili cowwoc wrote: > > Okay, I tracked down the crash. It's being caused by YACK() using a > 80-character buffer. The error message is longer than 80 characters, so > _snprintf_s() crashes to avoid a buffer overflow. > > Please apply the attached patch and add the zipped up Visual Studio > project directory. It's not perfect yet but it's a good start. > > Gili > > Trent Jarvi wrote: >> >> CVS HEAD is currently the rxtx 2.0 code. A branch was created long >> ago for 'experimental' gnu.io work. It just happens that the branch >> is what everyone uses now. >> >> checkout -r commapi-0-0-1 rxtx-devel >> >> will get the branch >> >> On Sun, 5 Apr 2009, cowwoc wrote: >> >>> Trent Jarvi wrote: >>>> It will compile with the msvc cl.exe and nmake. See Makefile.msvc >>>> in the top level directory. You will need to adjust the JAVA_HOME >>>> variable. Also use the MSVC command prompt for x86_64 so cl and >>>> nmake are on your path. >>> >>> This is very odd. The CVS version of the code does not contain >>> this file. Do you keep the latest code somewhere else? >>> >>> Gili >>> From tjarvi at qbang.org Sun Apr 5 16:13:27 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Apr 2009 16:13:27 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D920F9.6080702@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> <49D919A7.1070806@bbs.darktech.org> <49D920F9.6080702@bbs.darktech.org> Message-ID: Hi Gili, Are you using the cvs version? I thought we fixed the linked list issues. A solution was posted to the list. Let me look at work tomorrow to see what I have. On Sun, 5 Apr 2009, cowwoc wrote: > > My mistake. The problem in YACK is real, but it isn't the real cause > of the crash. The crash is caused by termios.c line 1099: > > index->prev->next = port; > > because in my case "index->prev==0". I think the bug is that the code > assumes that index will contain a minimum of two entries if we're inserting a > previously closed fd. In my case, it only contains one. > > I'm not sure why you have this code branch (as opposed to appending > to the end of index). Please take a look. > > Thanks, > Gili > > cowwoc wrote: >> >> Okay, I tracked down the crash. It's being caused by YACK() using a >> 80-character buffer. The error message is longer than 80 characters, so >> _snprintf_s() crashes to avoid a buffer overflow. >> >> Please apply the attached patch and add the zipped up Visual Studio >> project directory. It's not perfect yet but it's a good start. >> >> Gili >> >> Trent Jarvi wrote: >>> >>> CVS HEAD is currently the rxtx 2.0 code. A branch was created long ago >>> for 'experimental' gnu.io work. It just happens that the branch is what >>> everyone uses now. >>> >>> checkout -r commapi-0-0-1 rxtx-devel >>> >>> will get the branch >>> >>> On Sun, 5 Apr 2009, cowwoc wrote: >>> >>>> Trent Jarvi wrote: >>>>> It will compile with the msvc cl.exe and nmake. See Makefile.msvc in >>>>> the top level directory. You will need to adjust the JAVA_HOME >>>>> variable. Also use the MSVC command prompt for x86_64 so cl and nmake >>>>> are on your path. >>>> >>>> This is very odd. The CVS version of the code does not contain this >>>> file. Do you keep the latest code somewhere else? >>>> >>>> Gili >>>> > From ilkka at myller.com Sun Apr 5 23:58:08 2009 From: ilkka at myller.com (Ilkka Myller) Date: Mon, 6 Apr 2009 08:58:08 +0300 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> <49D919A7.1070806@bbs.darktech.org> <49D920F9.6080702@bbs.darktech.org> Message-ID: <19779C97-E0C7-4E3D-B715-F84F50F00CE6@myller.com> Hi all, I've already submitted the patch to fix this issue in february: http://mailman.qbang.org/pipermail/rxtx/2009-February/3989441.html The patch fixes the mentioned doubly linked list handling in termios.c -- I Trent Jarvi kirjoitti 6.4.2009 kello 1.13: > > Hi Gili, > > Are you using the cvs version? I thought we fixed the linked list > issues. > A solution was posted to the list. Let me look at work tomorrow to > see > what I have. > > > > On Sun, 5 Apr 2009, cowwoc wrote: > >> >> My mistake. The problem in YACK is real, but it isn't the real cause >> of the crash. The crash is caused by termios.c line 1099: >> >> index->prev->next = port; >> >> because in my case "index->prev==0". I think the bug is that the >> code >> assumes that index will contain a minimum of two entries if we're >> inserting a >> previously closed fd. In my case, it only contains one. >> >> I'm not sure why you have this code branch (as opposed to appending >> to the end of index). Please take a look. >> >> Thanks, >> Gili >> >> cowwoc wrote: >>> >>> Okay, I tracked down the crash. It's being caused by YACK() >>> using a >>> 80-character buffer. The error message is longer than 80 >>> characters, so >>> _snprintf_s() crashes to avoid a buffer overflow. >>> >>> Please apply the attached patch and add the zipped up Visual >>> Studio >>> project directory. It's not perfect yet but it's a good start. >>> >>> Gili >>> >>> Trent Jarvi wrote: >>>> >>>> CVS HEAD is currently the rxtx 2.0 code. A branch was created >>>> long ago >>>> for 'experimental' gnu.io work. It just happens that the branch >>>> is what >>>> everyone uses now. >>>> >>>> checkout -r commapi-0-0-1 rxtx-devel >>>> >>>> will get the branch >>>> >>>> On Sun, 5 Apr 2009, cowwoc wrote: >>>> >>>>> Trent Jarvi wrote: >>>>>> It will compile with the msvc cl.exe and nmake. See >>>>>> Makefile.msvc in >>>>>> the top level directory. You will need to adjust the JAVA_HOME >>>>>> variable. Also use the MSVC command prompt for x86_64 so cl and >>>>>> nmake >>>>>> are on your path. >>>>> >>>>> This is very odd. The CVS version of the code does not >>>>> contain this >>>>> file. Do you keep the latest code somewhere else? >>>>> >>>>> Gili >>>>> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Steffen.DETTMER at ingenico.com Mon Apr 6 02:53:47 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 6 Apr 2009 10:53:47 +0200 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D919A7.1070806@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> <49D919A7.1070806@bbs.darktech.org> Message-ID: <20090406085347.GM8289@elberon.bln.de.ingenico.com> Hi, just two minor details, first about the errno change, I though #include extern int errno; is correct (POSIX.1) - why this change? second about the log message, I think the maximum length could be limited and the return value of malloc must be checked for != NULL before using. Should it be _snprintf_s( message, 80, _TRUNCATE, "Error 0x%x at %s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); (I know that MS-CRT _snprintf does not guarantee to have a final EOS, but I think _snprintf_s with _TRUNCATE does so?). If it is known that truncation may happen maybe sizeof[message] could be increased; maybe using some %.20s could be used avoiding __FILE__ including big pathes to a message where all the message had been cut-off. To have it portable I think it could be: /* generally: */ #if defined(_MSC_VER) # define snprintf _snprintf #endif snprintf(message, sizeof(message), "Error 0x%x at %.20s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); message[sizeof(message)-1] = '\0'; /* needed for MS CRT snprintf */ (for length and size parameter I think size_t could be an option, but on several platforms, including MS-CRT and older glibc, there is no %z, unfortunately) oki, Steffen * cowwoc wrote on Sun, Apr 05, 2009 at 16:50 -0400: > > Okay, I tracked down the crash. It's being caused by YACK() using a > 80-character buffer. The error message is longer than 80 characters, so > _snprintf_s() crashes to avoid a buffer overflow. > > Please apply the attached patch and add the zipped up Visual Studio > project directory. It's not perfect yet but it's a good start. > > Gili > > Trent Jarvi wrote: > > > >CVS HEAD is currently the rxtx 2.0 code. A branch was created long > >ago for 'experimental' gnu.io work. It just happens that the branch > >is what everyone uses now. > > > >checkout -r commapi-0-0-1 rxtx-devel > > > >will get the branch > > > >On Sun, 5 Apr 2009, cowwoc wrote: > > > >>Trent Jarvi wrote: > >>>It will compile with the msvc cl.exe and nmake. See Makefile.msvc > >>>in the top level directory. You will need to adjust the JAVA_HOME > >>>variable. Also use the MSVC command prompt for x86_64 so cl and > >>>nmake are on your path. > >> > >> This is very odd. The CVS version of the code does not contain > >>this file. Do you keep the latest code somewhere else? > >> > >>Gili > >> > Index: ParallelImp.c > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/ParallelImp.c,v > retrieving revision 1.15.2.36 > diff -u -r1.15.2.36 ParallelImp.c > --- ParallelImp.c 11 Feb 2009 01:04:19 -0000 1.15.2.36 > +++ ParallelImp.c 5 Apr 2009 17:55:23 -0000 > @@ -119,7 +119,7 @@ > # include > #endif > > -extern int errno; > +_CRTIMP extern int * __cdecl _errno(void); > > #include "ParallelImp.h" > > @@ -181,8 +181,6 @@ > > #if defined (WIN32) > > -#define CTL_CODE( DeviceType, Function, Method, Access ) (((DeviceType) << 16) | ((Access) << 14) | ((Function) << 2) | (Method)) > - > #define FILE_DEVICE_PARALLEL_PORT 0x00000016 > #define METHOD_BUFFERED 0 > #define FILE_ANY_ACCESS 0 > @@ -253,7 +251,6 @@ > jobject jobj) > { > int fd = get_java_var( env, jobj,"fd","I" ); > - int status; > #if defined (__linux__) > ioctl(fd, LPGETSTATUS, &status); > #elif defined (WIN32) > Index: SerialImp.c > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v > retrieving revision 1.46.2.203 > diff -u -r1.46.2.203 SerialImp.c > --- SerialImp.c 19 Mar 2009 03:27:48 -0000 1.46.2.203 > +++ SerialImp.c 5 Apr 2009 17:49:48 -0000 > @@ -147,7 +147,7 @@ > #include > #endif /* LIBLOCKDEV */ > > -extern int errno; > +_CRTIMP extern int * __cdecl _errno(void); > > #include "SerialImp.h" > > Index: termios.c > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/termios.c,v > retrieving revision 1.9.2.62 > diff -u -r1.9.2.62 termios.c > --- termios.c 13 Jan 2009 03:08:55 -0000 1.9.2.62 > +++ termios.c 5 Apr 2009 17:54:09 -0000 > @@ -88,7 +88,7 @@ > #define SIGIO 0 > > int my_errno; > -extern int errno; > +_CRTIMP extern int * __cdecl _errno(void); > struct termios_list > { > char filename[80]; > @@ -1350,7 +1350,7 @@ > In that case use EAGAIN. See SerialImp.c:testRead() > ----------------------------------------------------------*/ > > -int serial_read( int fd, void *vb, int size ) > +int serial_read( int fd, void *vb, unsigned int size ) > { > long start, now; > unsigned long nBytes = 0, total = 0, error; > Index: win32termios.h > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/win32termios.h,v > retrieving revision 1.5.2.34 > diff -u -r1.5.2.34 win32termios.h > --- win32termios.h 5 Feb 2009 01:25:05 -0000 1.5.2.34 > +++ win32termios.h 5 Apr 2009 20:29:30 -0000 > @@ -60,6 +60,7 @@ > #include > #include > #include > +#include > #ifdef TRACE > #define ENTER(x) report("entering "x" \n"); > #define LEAVE(x) report("leaving "x" \n"); > @@ -70,8 +71,9 @@ > #if defined(_MSC_VER) > #define YACK() \ > { \ > - char *allocTextBuf, message[80]; \ > - unsigned long nChars; \ > + char *allocTextBuf, *message; \ > + const unsigned short longestNumber = 20; \ > + unsigned long nChars, len; \ > unsigned int errorCode = GetLastError(); \ > nChars = FormatMessage ( \ > FORMAT_MESSAGE_ALLOCATE_BUFFER | \ > @@ -82,8 +84,12 @@ > (LPSTR)&allocTextBuf, \ > 16, \ > NULL ); \ > - _snprintf_s( message, 80, 80, "Error 0x%x at %s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); \ > + len = strlen("Error 0x") + longestNumber + strlen(" at ") + strlen(__FILE__) + longestNumber + \ > + strlen(": ") + ((nChars+1) * sizeof(TCHAR)) + 1; \ > + message = malloc(len); \ > + _snprintf_s( message, len, len - 1, "Error 0x%x at %s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); \ > report_error( message ); \ > + free(message); \ > LocalFree(allocTextBuf); \ > Sleep(1); \ > } > @@ -173,7 +179,7 @@ > int serial_test( char * ); > int serial_open(const char *File, int flags, ... ); > int serial_close(int fd); > -int serial_read(int fd, void *b, int size); > +int serial_read(int fd, void *b, unsigned int size); > int serial_write(int fd, char *Str, int length); > /* > * lcc winsock.h conflicts > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx End of message. ------------------------------------------------------------------->8======= About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From bill7007 at gmail.com Mon Apr 6 16:34:50 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Mon, 6 Apr 2009 18:34:50 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: <49D693BA.8060909@gatworks.com> References: <49D546F8.20807@gatworks.com> <49D693BA.8060909@gatworks.com> Message-ID: Once it hung, three stack dumps minutes apart were exactly the same. I have a noticed that when it hangs, the read appears after flush() enter and before flush leave() that doesn't happen like: RXTXPort:SerialOutputStream:flush() enter RXTXPort:SerialInputStream:read(8192 0 8192) called When it works, flush() enter and leave happen together. It may just be because flush() hangs and read is the only other thread waiting to run at that point. I don't know much about the RXTX design and kernel interaction, just digging through the code some. Is there a design description somewhere? Am hung up on target system compile since UTS_RELEASE seems no longer defined for 2.6.18 up kernels and have not figured a good patch yet. But, that is another issue. Thanks for the good help. On Fri, Apr 3, 2009 at 6:54 PM, U. George wrote: > I would have tried 2 or 3 "^\" . If things are stuck, then all will be at > same 'java' instruction. If thread is moving, then one of the snapshots > would be different. > > I *think* flushing/draining wont return until the kernel buffers to device > have been accepted by device. Stuck/paused device? > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090406/c4b509d8/attachment-0003.html From tjarvi at qbang.org Mon Apr 6 17:45:38 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 6 Apr 2009 17:45:38 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <20090406085347.GM8289@elberon.bln.de.ingenico.com> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> <49D919A7.1070806@bbs.darktech.org> <20090406085347.GM8289@elberon.bln.de.ingenico.com> Message-ID: The error bits in the patch can probably just be dropped out. I don't see what they solve. Your snprintf define appears to work. The following is what I'd like to put in if noone objects. #if defined(_MSC_VER) # define snprintf _snprintf #endif #define YACK() \ { \ char *allocTextBuf, message[80]; \ unsigned long nChars; \ unsigned int errorCode = GetLastError(); \ nChars = FormatMessage ( \ FORMAT_MESSAGE_ALLOCATE_BUFFER | \ FORMAT_MESSAGE_FROM_SYSTEM, \ NULL, \ errorCode, \ MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT), \ (LPSTR)&allocTextBuf, \ 16, \ NULL ); \ snprintf( message, 80, "Error 0x%x at %s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); \ message[sizeof(message)-1] = '\0'; /* needed for MS CRT snprintf */ \ report_error( message ); \ LocalFree(allocTextBuf); \ Sleep(1); \ } On Mon, 6 Apr 2009, Steffen DETTMER wrote: > Hi, > > just two minor details, first about the errno change, I though > > #include > extern int errno; > > is correct (POSIX.1) - why this change? > > second about the log message, I think the maximum length could be > limited and the return value of malloc must be checked for != > NULL before using. > > Should it be > > _snprintf_s( message, 80, _TRUNCATE, "Error 0x%x at %s(%d): %s\n", > errorCode, __FILE__, __LINE__, allocTextBuf); > > (I know that MS-CRT _snprintf does not guarantee to have a final > EOS, but I think _snprintf_s with _TRUNCATE does so?). > > If it is known that truncation may happen maybe sizeof[message] > could be increased; maybe using some %.20s could be used avoiding > __FILE__ including big pathes to a message where all the message > had been cut-off. > > To have it portable I think it could be: > > /* generally: */ > #if defined(_MSC_VER) > # define snprintf _snprintf > #endif > > snprintf(message, sizeof(message), "Error 0x%x at %.20s(%d): %s\n", > errorCode, __FILE__, __LINE__, allocTextBuf); > message[sizeof(message)-1] = '\0'; /* needed for MS CRT snprintf */ > > (for length and size parameter I think size_t could be an option, > but on several platforms, including MS-CRT and older glibc, > there is no %z, unfortunately) > > oki, > > Steffen > > > * cowwoc wrote on Sun, Apr 05, 2009 at 16:50 -0400: >> >> Okay, I tracked down the crash. It's being caused by YACK() using a >> 80-character buffer. The error message is longer than 80 characters, so >> _snprintf_s() crashes to avoid a buffer overflow. >> >> Please apply the attached patch and add the zipped up Visual Studio >> project directory. It's not perfect yet but it's a good start. >> >> Gili >> >> Trent Jarvi wrote: >> > >> >CVS HEAD is currently the rxtx 2.0 code. A branch was created long >> >ago for 'experimental' gnu.io work. It just happens that the branch >> >is what everyone uses now. >> > >> >checkout -r commapi-0-0-1 rxtx-devel >> > >> >will get the branch >> > >> >On Sun, 5 Apr 2009, cowwoc wrote: >> > >> >>Trent Jarvi wrote: >> >>>It will compile with the msvc cl.exe and nmake. See Makefile.msvc >> >>>in the top level directory. You will need to adjust the JAVA_HOME >> >>>variable. Also use the MSVC command prompt for x86_64 so cl and >> >>>nmake are on your path. >> >> >> >> This is very odd. The CVS version of the code does not contain >> >>this file. Do you keep the latest code somewhere else? >> >> >> >>Gili >> >> > >> Index: ParallelImp.c >> =================================================================== >> RCS file: /usr/local/cvsroot/rxtx-devel/src/ParallelImp.c,v >> retrieving revision 1.15.2.36 >> diff -u -r1.15.2.36 ParallelImp.c >> --- ParallelImp.c 11 Feb 2009 01:04:19 -0000 1.15.2.36 >> +++ ParallelImp.c 5 Apr 2009 17:55:23 -0000 >> @@ -119,7 +119,7 @@ >> # include >> #endif >> >> -extern int errno; >> +_CRTIMP extern int * __cdecl _errno(void); >> >> #include "ParallelImp.h" >> >> @@ -181,8 +181,6 @@ >> >> #if defined (WIN32) >> >> -#define CTL_CODE( DeviceType, Function, Method, Access ) (((DeviceType) << 16) | ((Access) << 14) | ((Function) << 2) | (Method)) >> - >> #define FILE_DEVICE_PARALLEL_PORT 0x00000016 >> #define METHOD_BUFFERED 0 >> #define FILE_ANY_ACCESS 0 >> @@ -253,7 +251,6 @@ >> jobject jobj) >> { >> int fd = get_java_var( env, jobj,"fd","I" ); >> - int status; >> #if defined (__linux__) >> ioctl(fd, LPGETSTATUS, &status); >> #elif defined (WIN32) >> Index: SerialImp.c >> =================================================================== >> RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v >> retrieving revision 1.46.2.203 >> diff -u -r1.46.2.203 SerialImp.c >> --- SerialImp.c 19 Mar 2009 03:27:48 -0000 1.46.2.203 >> +++ SerialImp.c 5 Apr 2009 17:49:48 -0000 >> @@ -147,7 +147,7 @@ >> #include >> #endif /* LIBLOCKDEV */ >> >> -extern int errno; >> +_CRTIMP extern int * __cdecl _errno(void); >> >> #include "SerialImp.h" >> >> Index: termios.c >> =================================================================== >> RCS file: /usr/local/cvsroot/rxtx-devel/src/termios.c,v >> retrieving revision 1.9.2.62 >> diff -u -r1.9.2.62 termios.c >> --- termios.c 13 Jan 2009 03:08:55 -0000 1.9.2.62 >> +++ termios.c 5 Apr 2009 17:54:09 -0000 >> @@ -88,7 +88,7 @@ >> #define SIGIO 0 >> >> int my_errno; >> -extern int errno; >> +_CRTIMP extern int * __cdecl _errno(void); >> struct termios_list >> { >> char filename[80]; >> @@ -1350,7 +1350,7 @@ >> In that case use EAGAIN. See SerialImp.c:testRead() >> ----------------------------------------------------------*/ >> >> -int serial_read( int fd, void *vb, int size ) >> +int serial_read( int fd, void *vb, unsigned int size ) >> { >> long start, now; >> unsigned long nBytes = 0, total = 0, error; >> Index: win32termios.h >> =================================================================== >> RCS file: /usr/local/cvsroot/rxtx-devel/src/win32termios.h,v >> retrieving revision 1.5.2.34 >> diff -u -r1.5.2.34 win32termios.h >> --- win32termios.h 5 Feb 2009 01:25:05 -0000 1.5.2.34 >> +++ win32termios.h 5 Apr 2009 20:29:30 -0000 >> @@ -60,6 +60,7 @@ >> #include >> #include >> #include >> +#include >> #ifdef TRACE >> #define ENTER(x) report("entering "x" \n"); >> #define LEAVE(x) report("leaving "x" \n"); >> @@ -70,8 +71,9 @@ >> #if defined(_MSC_VER) >> #define YACK() \ >> { \ >> - char *allocTextBuf, message[80]; \ >> - unsigned long nChars; \ >> + char *allocTextBuf, *message; \ >> + const unsigned short longestNumber = 20; \ >> + unsigned long nChars, len; \ >> unsigned int errorCode = GetLastError(); \ >> nChars = FormatMessage ( \ >> FORMAT_MESSAGE_ALLOCATE_BUFFER | \ >> @@ -82,8 +84,12 @@ >> (LPSTR)&allocTextBuf, \ >> 16, \ >> NULL ); \ >> - _snprintf_s( message, 80, 80, "Error 0x%x at %s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); \ >> + len = strlen("Error 0x") + longestNumber + strlen(" at ") + strlen(__FILE__) + longestNumber + \ >> + strlen(": ") + ((nChars+1) * sizeof(TCHAR)) + 1; \ >> + message = malloc(len); \ >> + _snprintf_s( message, len, len - 1, "Error 0x%x at %s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); \ >> report_error( message ); \ >> + free(message); \ >> LocalFree(allocTextBuf); \ >> Sleep(1); \ >> } >> @@ -173,7 +179,7 @@ >> int serial_test( char * ); >> int serial_open(const char *File, int flags, ... ); >> int serial_close(int fd); >> -int serial_read(int fd, void *b, int size); >> +int serial_read(int fd, void *b, unsigned int size); >> int serial_write(int fd, char *Str, int length); >> /* >> * lcc winsock.h conflicts >> > > >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > > > > > > > > > > > > End of message. > ------------------------------------------------------------------->8======= > > > About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. > This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > P Please consider the environment before printing this e-mail > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Apr 6 18:11:28 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 6 Apr 2009 18:11:28 -0600 (MDT) Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: <49D546F8.20807@gatworks.com> <49D693BA.8060909@gatworks.com> Message-ID: UTS_RELEASE is defined in now. The check really should be removed from RXTX. It was a defensive check for wilder times when GNU glibc did not have defines the kernel headers had so rxtx would include the kernel headers instead. :/ If you don't have linux/version.h, it is generated when you configure the kernel. make oldconfig used to do the trick. It may make sense to work with the prerelease or CVS code. RXTX just assumes that flush, read and anything else the kernel exposes may be called at anytime from any thread. There isn't a design for the kernel interaction. There are higher level constraints put in Java to prevent some things happening at the same time with 'synchronized.' RXTXPort.java has all of those. When the port is opened, a native event thread is started which uses select to know if an event has happened. BSD like systems have a native thread that fires off on write which tries to flush() to determine when the output buffer is empty asynchronously. The rest is not marshaled in any fashion at the native level. T I think there is a lower level deadlock being triggered in flush as well. I don't think it should be possible if everything was right underneath us. You may want to examine the java code closer to make sure it isnt possible the lock is there. On Mon, 6 Apr 2009, Bill Johnson wrote: > Once it hung, three stack dumps minutes apart were exactly the same. > I have a noticed that when it hangs, the read appears after flush() enter and > before flush leave() that doesn't happen like: > RXTXPort:SerialOutputStream:flush() enter > RXTXPort:SerialInputStream:read(8192 0 8192) called > > When it works, flush() enter and leave happen together. It may just be because > flush() hangs and read is the only other thread waiting to run at that point. > I don't know much about the RXTX design and kernel interaction, just digging > through the code some. Is there a design description somewhere? > > Am hung up on target system compile since UTS_RELEASE seems no longer defined for > 2.6.18 up kernels and have not figured a good patch yet. But, that is another > issue. > > Thanks for the good help. > > > On Fri, Apr 3, 2009 at 6:54 PM, U. George wrote: > I would have tried 2 or 3 "^\" . If things are stuck, then all will be > at same 'java' instruction. If thread is moving, then one of the > snapshots would be different. > > I *think* flushing/draining wont return until the kernel buffers to > device have been accepted by device. Stuck/paused device? > > > > > From tjarvi at qbang.org Mon Apr 6 18:28:50 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 6 Apr 2009 18:28:50 -0600 (MDT) Subject: [Rxtx] CVS updates. Pre3 is comming. Message-ID: I need to go through the bugzilla reports prior to the pre3 release. I think this should be close if you want to check it out from CVS. added: YACK() debug overflow fix for windows Steffen DETTMER (and many others) multiport fix for windows. Ilkka Myller http://mailman.qbang.org/pipermail/rxtx/2009-February/3989441.html I think this code is current. If I missed something, yell. CVS Info: export/setenv CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login # passwd mousy cvs checkout -r commapi-0-0-1 rxtx-devel -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Apr 6 22:32:07 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 6 Apr 2009 22:32:07 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D919A7.1070806@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> <49D919A7.1070806@bbs.darktech.org> Message-ID: Ah. I'll put this in CVS tomorrow. I did sync up the code with my work sandbox today. I just forgot to pull and add this. On Sun, 5 Apr 2009, cowwoc wrote: > > Okay, I tracked down the crash. It's being caused by YACK() using a > 80-character buffer. The error message is longer than 80 characters, so > _snprintf_s() crashes to avoid a buffer overflow. > > Please apply the attached patch and add the zipped up Visual Studio > project directory. It's not perfect yet but it's a good start. > > Gili > > Trent Jarvi wrote: >> >> CVS HEAD is currently the rxtx 2.0 code. A branch was created long ago for >> 'experimental' gnu.io work. It just happens that the branch is what >> everyone uses now. >> >> checkout -r commapi-0-0-1 rxtx-devel >> >> will get the branch >> >> On Sun, 5 Apr 2009, cowwoc wrote: >> >>> Trent Jarvi wrote: >>>> It will compile with the msvc cl.exe and nmake. See Makefile.msvc in the >>>> top level directory. You will need to adjust the JAVA_HOME variable. >>>> Also use the MSVC command prompt for x86_64 so cl and nmake are on your >>>> path. >>> >>> This is very odd. The CVS version of the code does not contain this >>> file. Do you keep the latest code somewhere else? >>> >>> Gili >>> > From cowwoc at bbs.darktech.org Tue Apr 7 06:07:46 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Tue, 07 Apr 2009 08:07:46 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: References: Message-ID: <49DB4212.40807@bbs.darktech.org> > just two minor details, first about the errno change, I though > > #include > extern int errno; > > is correct (POSIX.1) - why this change? If you compile this under Visual Studio 2008 you will get warnings that the errno type being imported is different from the type being exported. The definition I pasted is the one being exported. Perhaps we should use #ifdef WIN32 for this? Gili From bill7007 at gmail.com Tue Apr 7 17:58:54 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Tue, 7 Apr 2009 19:58:54 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: <49D546F8.20807@gatworks.com> <49D693BA.8060909@gatworks.com> Message-ID: I have traced the hang down to a call to tcdrain(fd) in SerialImp.c:drain() running and rebuilt under Netbeans on the target machine with debug messages on. That puts it into the system code, so I'm not sure how to proceed. I guess I could debug into the kernel source but I've not done that. I saw some discussion about an IOCTL that sets/adjusts a timeout on tcdrain() but that may have been for BSD. Maybe there is some new setup requirement or bug introduced with this 2.6.18 kernel or a hardware difference. Below is a message listing with some of the repeated parts removed. Maybe you can see something noteworthy? JNI_OnLoad called. WARNING: RXTX Version mismatch Jar version = RXTX-2.2pre2 native lib Version = RXTX-2.2pre3 entering RXTXCommDriver:getDeviceDirectory entering RXTXPort:testRead fhs_lock: creating lockfile: 29704 fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXPort:testRead RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB2 fhs_lock: creating lockfile: 29704 fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXPort:testRead RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB1 fhs_lock: creating lockfile: 29704 fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXPort:testRead RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB0 fhs_lock: creating lockfile: 29704 fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXPort:testRead fhs_lock: creating lockfile: 29704 ... REPEATS fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXPort:testRead fhs_lock: creating lockfile: 29704 fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXCommDriver:getDeviceDirectory entering RXTXPort:testRead fhs_lock: creating lockfile: 29704 ...REPEATS fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXPort:testRead fhs_lock: creating lockfile: 29704 fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXPort:Initialize RXTX WARNING: This library was compiled to run with OS release 2.6.18 and you are currently running OS release 2.6.18-92.1.6.el5. In some cases this can be a problem. Try recompiling RXTX if you notice strange behavior. If you just compiled RXTX make sure /usr/include/linux is a symbolic link to the include files that came with the kernel source and not an older copy. press enter to continue leaving RXTXPort:Initialize entering RXTXPort:open fhs_lock: creating lockfile: 29704 open: locking worked for /dev/ttyUSB2 open: fd returned is 9 leaving RXTXPort:open entering eventLoop has_line_status_register_acess: Port does not support TIOCSERGETLSR driver_has_tiocgicount: Port does not support TIOCGICOUNT events init_threads: get eis init_threads: set eis init_threads: stop leaving RXTXPort:translate_speed entering RXTXPort:nativeSetSerialPortParams entering translate_date_bits entering translate_stop_bits leaving RXTXPort:translate_stop_bits entering translate_parity leaving translate_parity entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 ...REPEATS entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 leaving RXTXPort:nativeSetSerialPortParams entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 ...REPEATS entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 entering writeArray entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 writeArray() leaving RXTXPort:writeArray entering SerialImp.c:drain() nativeDrain: trying tcdrain RXTXPort:drain() returns: 0 leaving RXTXPort:drain() entering writeArray writeArray() leaving RXTXPort:writeArray entering SerialImp.c:drain() nativeDrain: trying tcdrain entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 Tue Apr 07 18:51:49 EDT 2009:TSerial[22]:Using Port:/dev/ttyUSB2 Tue Apr 07 18:51:49 EDT 2009:TSerial[22].Transmit:TN Tue Apr 07 18:51:49 EDT 2009:TSerial[22].Transmit:RV entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 ...REPEATS FOREVER? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090407/f26e5752/attachment-0002.html From tjarvi at qbang.org Tue Apr 7 18:31:23 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 7 Apr 2009 18:31:23 -0600 (MDT) Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: <49D546F8.20807@gatworks.com> <49D693BA.8060909@gatworks.com> Message-ID: On Tue, 7 Apr 2009, Bill Johnson wrote: > I have traced the hang down to a call to tcdrain(fd) in SerialImp.c:drain() > running and rebuilt under Netbeans on the target machine with debug messages > on. That puts it into the system code, so I'm not sure how to proceed. I > guess I could debug into the kernel source but I've not done that. I saw > some discussion about an IOCTL that sets/adjusts a timeout on tcdrain() but > that may have been for BSD. Maybe there is some new setup requirement or bug > introduced with this 2.6.18 kernel or a hardware difference. > Below is a message listing with some of the repeated parts removed. Maybe > you can see something noteworthy? > > JNI_OnLoad called. > WARNING:? RXTX Version mismatch > ??????? Jar version = RXTX-2.2pre2 > ??????? native lib Version = RXTX-2.2pre3 > entering RXTXCommDriver:getDeviceDirectory > entering RXTXPort:testRead > fhs_lock: creating lockfile:????? 29704 > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXPort:testRead > RXTX Warning:? Removing stale lock file. /var/lock/LCK..ttyUSB2 > fhs_lock: creating lockfile:????? 29704 > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXPort:testRead > RXTX Warning:? Removing stale lock file. /var/lock/LCK..ttyUSB1 > fhs_lock: creating lockfile:????? 29704 > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXPort:testRead > RXTX Warning:? Removing stale lock file. /var/lock/LCK..ttyUSB0 > fhs_lock: creating lockfile:????? 29704 > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXPort:testRead > fhs_lock: creating lockfile:????? 29704 > > ... REPEATS > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXPort:testRead > fhs_lock: creating lockfile:????? 29704 > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXCommDriver:getDeviceDirectory > entering RXTXPort:testRead > fhs_lock: creating lockfile:????? 29704 > > ...REPEATS > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXPort:testRead > fhs_lock: creating lockfile:????? 29704 > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXPort:Initialize > > > > RXTX WARNING:? This library was compiled to run with OS release 2.6.18 and > you are currently running OS release 2.6.18-92.1.6.el5.? In some cases this > can be a problem.? Try recompiling RXTX if you notice strange behavior.? If > you just compiled RXTX make sure /usr/include/linux is a symbolic link to > the include files that came with the kernel source and not an older copy. > > > press enter to continue > > leaving RXTXPort:Initialize > entering RXTXPort:open > fhs_lock: creating lockfile:????? 29704 > > open: locking worked for /dev/ttyUSB2 > open: fd returned is 9 > leaving RXTXPort:open > entering eventLoop > ? > has_line_status_register_acess: Port does not support TIOCSERGETLSR > ?driver_has_tiocgicount:? Port does not support TIOCGICOUNT events > init_threads: get eis > init_threads: set eis > init_threads:? stop > leaving RXTXPort:translate_speed > entering RXTXPort:nativeSetSerialPortParams > entering translate_date_bits > entering translate_stop_bits > leaving RXTXPort:translate_stop_bits > entering translate_parity > leaving translate_parity > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > ...REPEATS > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > leaving RXTXPort:nativeSetSerialPortParams > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > ...REPEATS > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > entering writeArray > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > writeArray() > leaving RXTXPort:writeArray > entering SerialImp.c:drain() > nativeDrain: trying tcdrain > RXTXPort:drain() returns: 0 > leaving RXTXPort:drain() > entering writeArray > writeArray() > leaving RXTXPort:writeArray > entering SerialImp.c:drain() > nativeDrain: trying tcdrain > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > Tue Apr 07 18:51:49 EDT 2009:TSerial[22]:Using Port:/dev/ttyUSB2 > Tue Apr 07 18:51:49 EDT 2009:TSerial[22].Transmit:TN > > Tue Apr 07 18:51:49 EDT 2009:TSerial[22].Transmit:RV > > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > ...REPEATS FOREVER? > > > Hi Bill ugh. The tiocmget... is the eventLoop checking for events. It sits with select() but has a timeout value to keep it spinning at a trivial rate. tcdrain() is the suspect. I don't see anything in the code that looks like a problem. If flow control is not enabled, I don't see a reason for it not to return. Given that this is USB, perhaps a message from the device got lost. Onboard UARTs would have a status register change when output buffer is empty. USB needs to communicate the event as an HID device which may be the source of the error. Dropping back to onboard UARTs eliminates that portion of the mix. What vendor/chipset is the USB dongle? I understand code has been pushed upon the linux serial devices for new for things like acpi. There very well could be a bug introduced. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Apr 7 18:38:22 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 7 Apr 2009 18:38:22 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49DB4212.40807@bbs.darktech.org> References: <49DB4212.40807@bbs.darktech.org> Message-ID: On Tue, 7 Apr 2009, cowwoc wrote: >> just two minor details, first about the errno change, I though >> >> #include >> extern int errno; >> >> is correct (POSIX.1) - why this change? > > If you compile this under Visual Studio 2008 you will get warnings that > the errno type being imported is different from the type being exported. > The definition I pasted is the one being exported. Perhaps we should use > #ifdef WIN32 for this? > Hi Gili, Perhaps a workaround for _MSVC is in order. GNU compilers for windows won't complain. If it's a question of MSVC or POSIX being right, the library favors the standard as a stated goal. I'm not sure what MSVC is using errno for but it should not be using it except with POSIX extensions. Perhaps #undef is enough to get rid of the warning and (maybe) has no ill consequences. Newer windows have POSIX extensions that may show how Microsoft solved the problem. It can probably fester. -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Tue Apr 7 19:54:06 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Tue, 07 Apr 2009 21:54:06 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: References: <49DB4212.40807@bbs.darktech.org> Message-ID: <49DC03BE.5010203@bbs.darktech.org> Trent Jarvi wrote: > I'm not sure what MSVC is using errno for but it should not be using it > except with POSIX extensions. Perhaps #undef is enough to get rid of > the warning and (maybe) has no ill consequences. Newer windows have > POSIX extensions that may show how Microsoft solved the problem. > > It can probably fester. What does "newer windows" refer to in this case? I was compiling using Visual Studio 2008 sp1 under Windows Vista. Both are cutting edge technologies as far as official releases go. I think you're best suited to judge whether this warning is a big deal or not so I think you should see it for yourself. Please try firing up Visual Studio 2008 (express?) against the project I sent you. Gili From Steffen.DETTMER at ingenico.com Wed Apr 8 05:50:42 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 8 Apr 2009 13:50:42 +0200 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49DC03BE.5010203@bbs.darktech.org> References: <49DB4212.40807@bbs.darktech.org> <49DC03BE.5010203@bbs.darktech.org> Message-ID: <20090408115042.GC5090@elberon.bln.de.ingenico.com> * cowwoc wrote on Tue, Apr 07, 2009 at 21:54 -0400: > Trent Jarvi wrote: > > I'm not sure what MSVC is using errno for but it should not be using it > > except with POSIX extensions. Perhaps #undef is enough to get rid of > > the warning and (maybe) has no ill consequences. Newer windows have > > POSIX extensions that may show how Microsoft solved the problem. I think here best is simply to omit this old^Wclassic `extern int errno;' line completely. I think standards just say something like `implementations may support the declaration extern int errno;'. About POSIX extensions I think in general it should be considered that althrough many things are available, even with MS Visual C++, the Microsoft tools lead developers to write non-portable code (and personally I think this is intentional). For example, they call the official ISO-C function `strerror' deprecated (!) and twaddle about some security enhancements (without even beeing specific). Someone could, because of this, lead to use the MS specific, unportable `strerror_s' instead. Even better, at _strerror_s they tell, for `ANSI compatiblity someone should use strerror_s'. Of course a program using [_]strerror_s won't be ANSI-C compliant. Do they mean strerror_r? _strerror_s has the same parameters - but of course in different order - to make porting a pain... SCNR. > What does "newer windows" refer to in this case? I was compiling using > Visual Studio 2008 sp1 under Windows Vista. Both are cutting edge > technologies as far as official releases go. `cutting edge technologies' yeah post-standard, portability-cutting technologies smoothing the way to MS world domination; own post-ANSI-C programming languages help (maybe to increase the share holder value)... SCNR. > I think you're best suited to judge whether this warning is a big deal > or not so I think you should see it for yourself. Please try firing up > Visual Studio 2008 (express?) against the project I sent you. yeah, getting the CL.EXE of 2008 running in a normal command line environment (without its special `C++ Shell') is a bit tricky - but possible. ;) oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From tjarvi at qbang.org Wed Apr 8 14:29:54 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 8 Apr 2009 14:29:54 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49DC03BE.5010203@bbs.darktech.org> References: <49DB4212.40807@bbs.darktech.org> <49DC03BE.5010203@bbs.darktech.org> Message-ID: The support has been around for a long time to. I don't know the details but the support appears to be tied to the OS. http://en.wikipedia.org/wiki/POSIX#POSIX_for_Windows On Tue, 7 Apr 2009, cowwoc wrote: > Trent Jarvi wrote: >> I'm not sure what MSVC is using errno for but it should not be using it >> except with POSIX extensions. Perhaps #undef is enough to get rid of the >> warning and (maybe) has no ill consequences. Newer windows have POSIX >> extensions that may show how Microsoft solved the problem. >> >> It can probably fester. > > What does "newer windows" refer to in this case? I was compiling > using Visual Studio 2008 sp1 under Windows Vista. Both are cutting edge > technologies as far as official releases go. > > I think you're best suited to judge whether this warning is a big > deal or not so I think you should see it for yourself. Please try firing up > Visual Studio 2008 (express?) against the project I sent you. > > Gili > From bill7007 at gmail.com Wed Apr 8 15:59:08 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Wed, 8 Apr 2009 17:59:08 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: <49D546F8.20807@gatworks.com> <49D693BA.8060909@gatworks.com> Message-ID: Hi Trent, I think I have hit on a work around but don't know why it works. The USB serial adapter is a "CableMAX" based on Prolific's PL2303. Backing out to the big picture, the application is old and has been very reliable until put on a new cpu and kernel. It only hangs sometimes say 25% and always at the same place, at tcdrain() on the flush() after the second write after startup. If it made it past this stage, all transmit and receive seemed reliable so it was like a startup timing issue. Since learning to debug kernel code is beyond my immediate priority, I took a shot at moving code around, adding delays, and such. I have found it good practice to do a flush after every write on streams like: outputStream.write(data.getBytes()); outputStream.flush(); If I remove the flush() after each write, the problem appears to go away! I don't think the flush is needed for a SerialOutputStream for this application anyway. Thanks for all the help, +BillJ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090408/35d96a9d/attachment.html From cowwoc at bbs.darktech.org Wed Apr 1 22:05:13 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Thu, 02 Apr 2009 00:05:13 -0400 Subject: [Rxtx] Windows 64-bit support? Message-ID: <49D43979.4050702@bbs.darktech.org> Hi, I'd like to run RXTX under the Windows 64-bit JVM. Are there plans to release an official 64-bit version anytime soon? Gili From bill7007 at gmail.com Thu Apr 2 16:01:17 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Thu, 2 Apr 2009 18:01:17 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel Message-ID: Hi, I have an rxtx serial application that used to work reliably until I had to move it to newer hardware and kernel. Now, the application sometimes hangs near first port use. When it does hang, it can be released by starting a second copy of the application which is locked out of the ports but does release the first process. Upgraded from rxtx-2.1-7-r2 to rxtx-2.2pre2 but still hangs. Tried to rebuild on the target machine and ran into the 'UTS_RELEASE' undeclared problem so holding on that approach. Recompiled OK on a 2.6.9-42.0.3.ELsmp system. Debug messages were turned on using: "./configure --enable-DEBUG" and modified RXTXPort.java with: "debug = true;" "z = new Zystem(Zystem.PRINT_MODE);" Below is capture of the application with debugging enabled. It show the application hang point, and the second application's printout at the release point. (pre3 is the locally modified version of pre2) Any suggestions on how to pin this down further? Thanks, +BillJ $ java -version java version "1.5.0_06" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05) Java HotSpot(TM) Client VM (build 1.5.0_06-b05, mixed mode, sharing) $ uname -a Linux qms4 2.6.18-92.1.6.el5 #1 SMP Wed Jun 25 13:49:24 EDT 2008 i686 i686 i386 GNU/Linux ***CAPTURE: [qms at qms4 ~]$ ./qms/ScriptFiles/startup.sh Thu Apr 02 13:35:45 EDT 2009:Setting Log File to:/home/qms/qms/QMS.log Thu Apr 02 13:35:45 EDT 2009:TSettings.HandleIni:ReUsing Ini file:/home/qms/qms/qms.properties WARNING: RXTX Version mismatch Jar version = RXTX-2.2pre2 native lib Version = RXTX-2.2pre3 fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB2 fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB1 fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB0 fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile RXTXPort {} RXTX WARNING: This library was compiled to run with OS release 2.4.20 and you are currently running OS release 2.6.18-92.1.6.el5. In some cases this can be a problem. Try recompiling RXTX if you notice strange behavior. If you just compiled RXTX make sure /usr/include/linux is a symbolic link to the include files that came with the kernel source and not an older copy. press enter to continue RXTXPort:RXTXPort(/dev/ttyUSB2) called fhs_lock: creating lockfile: 10127 open: locking worked for /dev/ttyUSB2 open: fd returned is 8 RXTXPort:MontitorThread:MonitorThread() RXTXPort:MontitorThread:run() has_line_status_register_acess: Port does not support TIOCSERGETLSR init_threads: get eis init_threads: set eis init_threads: stop RXTXPort:RXTXPort(/dev/ttyUSB2) returns with fd = 8 RXTXPort:setSerialPortParams(38400 8 1 0) called RXTXPort:setSerialPortParams(38400 8 1 0) returning RXTXPort:getInputStream() called and returning Thu Apr 02 13:36:02 EDT 2009:TSerial[22]:Using Port:/dev/ttyUSB2 RXTXPort:getOutputStream() called and returning Thu Apr 02 13:36:02 EDT 2009:TSerial[22].Transmit:TN Entering RXTXPort:SerialOutputStream:write(4) writeArray() Leaving RXTXPort:SerialOutputStream:write(4) RXTXPort:SerialOutputStream:flush() enter RXTXPort:SerialOutputStream:flush() leave Thu Apr 02 13:36:02 EDT 2009:TSerial[22].Transmit:RV Entering RXTXPort:SerialOutputStream:write(4) writeArray() Leaving RXTXPort:SerialOutputStream:write(4) RXTXPort:SerialOutputStream:flush() enter RXTXPort:SerialInputStream:read(8192 0 8192) called ***FIRST PROCESS HANGS HERE ***THEN PROCEEDS AFTER SECOND PROCESS STARTS RXTXPort:SerialOutputStream:flush() leave Thu Apr 02 13:41:29 EDT 2009:TSerial[22].Transmit:IH9 Entering RXTXPort:SerialOutputStream:write(5) writeArray() Leaving RXTXPort:SerialOutputStream:write(5) RXTXPort:SerialOutputStream:flush() enter RXTXPort:SerialOutputStream:flush() leave Thu Apr 02 13:41:29 EDT 2009:TSerial[22].Transmit:IL11 ***END CAPTURE ***CAPTURE SECOND PROCESS FAILS OPEN [qms at qms4 ~]$ ./qms/ScriptFiles/startup.sh Thu Apr 02 13:41:27 EDT 2009:Setting Log File to:/home/qms/qms/QMS.log Thu Apr 02 13:41:27 EDT 2009:TSettings.HandleIni:ReUsing Ini file:/home/qms/qms/qms.properties WARNING: RXTX Version mismatch Jar version = RXTX-2.2pre2 native lib Version = RXTX-2.2pre3 fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB2: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB1: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB0: File exists fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB2: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB1: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB0: File exists fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile Thu Apr 02 13:41:30 EDT 2009:TIOBoard: java.io.IOException: java.io.IOException: TSerial[22]: Open Failed ***END CAPTURE -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090402/c66f8d70/attachment-0008.html From netbeans at gatworks.com Thu Apr 2 17:15:04 2009 From: netbeans at gatworks.com (U. George) Date: Thu, 02 Apr 2009 19:15:04 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: Message-ID: <49D546F8.20807@gatworks.com> > "z = new Zystem(Zystem.PRINT_MODE);" > Below is capture of the application with debugging enabled. It show > the application hang point, and the second application's printout at the > release point. (pre3 is the locally modified version of pre2) > Any suggestions on how to pin this down further? > Thanks, > +BillJ When perceived runability is hung, try a ^\ ( control \) on console. This gets the JVM to dump the stacks of all the java threads. If you know the thread that is stuck, then u can see what java statement its stuck at. From tjarvi at qbang.org Thu Apr 2 19:25:17 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 2 Apr 2009 19:25:17 -0600 (MDT) Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: <49D546F8.20807@gatworks.com> References: <49D546F8.20807@gatworks.com> Message-ID: On Thu, 2 Apr 2009, U. George wrote: >> "z = new Zystem(Zystem.PRINT_MODE);" >> Below is capture of the application with debugging enabled. It show >> the application hang point, and the second application's printout at the >> release point. (pre3 is the locally modified version of pre2) >> Any suggestions on how to pin this down further? >> Thanks, >> +BillJ > > When perceived runability is hung, try a ^\ ( control \) on console. > This gets the JVM to dump the stacks of all the java threads. > If you know the thread that is stuck, then u can see what java statement > its stuck at. I've also noticed some linux systems hanging with open/read/write and saw kacpid storms. I need to look at it more but did observe kacpid consuming a core and not returning to a normal state for a significant period of time. It was easy to observe from top sorted by CPU usage. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Apr 2 19:26:18 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 2 Apr 2009 19:26:18 -0600 (MDT) Subject: [Rxtx] Windows 64-bit support? In-Reply-To: <49D43979.4050702@bbs.darktech.org> References: <49D43979.4050702@bbs.darktech.org> Message-ID: On Thu, 2 Apr 2009, cowwoc wrote: > Hi, > > I'd like to run RXTX under the Windows 64-bit JVM. Are there plans > to release an official 64-bit version anytime soon? > It is in the prerelease and will be in the final release. I'm pushing it through as fast as I can in my free time. -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Thu Apr 2 22:57:34 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Fri, 03 Apr 2009 00:57:34 -0400 Subject: [Rxtx] Missing documentation In-Reply-To: References: <49D43979.4050702@bbs.darktech.org> Message-ID: <49D5973E.4050400@bbs.darktech.org> Hi, I noticed that RXTX 2.1 drops javax.comm support in favor of gnu.io. I have one major problem with this: the gui.io.* documentation is very poor. Many classes and methods have no Javadoc at all which makes them difficult to use. Please fix this for the final release. Thank you, Gili From alex.sas at freemail.hu Fri Apr 3 01:36:54 2009 From: alex.sas at freemail.hu (Sas Alex) Date: Fri, 3 Apr 2009 09:36:54 +0200 (CEST) Subject: [Rxtx] Serial port false reads Message-ID: Hi all, On Windows XP, using rxtx-2.1-7-r2 I have a program communicating on a serial line like the following (excerpt): { os.write(command); os.flush(); // Thread.sleep(period); // read response while(is.available() > 0) { is.read() } } If there is a sleep between the os.flush and the reading cycle the correct answer is received. Otherwise (sometimes) there are extra, erronous characters at the beginning of the answer, but the correct answer (according to the protocol) also arrives, afterwards. Is this a normal behaviour, one should wait before the read? If yes, is there a way to determine the minimum amount of time to wait for? Serial port params are: 9600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE. Thank you in advance, Alex ________________________________________________________ El?foglal?si akci? meghosszabb?tva! Korfui ?d?l?s m?r 56.910 Ft-t?l. http://www.budavartours.hu/gorogorszag/?utm_campaign=origo&utm_source=freemail_kimeno_090403&utm_medium=ct&utm_content=korfu_elofoglalasi_akcio#reg_Korfu -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090403/8f3650ea/attachment-0008.html From bill7007 at gmail.com Fri Apr 3 16:15:30 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Fri, 3 Apr 2009 18:15:30 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: <49D546F8.20807@gatworks.com> Message-ID: > When perceived runability is hung, try a ^\ ( control \) on console. >> This gets the JVM to dump the stacks of all the java threads. > > Good idea... A thread dump is below, it looks like only some system threads are in wait state which is probably normal. The "main" thread is stopped writing the first data out the serial port which should complete but its has stopped at: at gnu.io.RXTXPort.nativeDrain(Native Method) It show its state as runnable though. There is another thread, "SerialReader_22", that is waiting to read any data on the same port. I'll bring the app up under Netbeans debugger next. >> > I've also noticed some linux systems hanging with open/read/write and saw > kacpid storms. No CPU use going when it hangs, acts like a deadlock. THREAD DUMP AT HANG: Entering RXTXPort:SerialOutputStream:write(4) writeArray() Leaving RXTXPort:SerialOutputStream:write(4) RXTXPort:SerialOutputStream:flush() enter RXTXPort:SerialInputStream:read(8192 0 8192) called Full thread dump Java HotSpot(TM) Client VM (1.5.0_06-b05 mixed mode, sharing): "SerialReader_22" daemon prio=1 tid=0x087abf38 nid=0x3c8b runnable [0xb1a43000..0xb1a43f30] at gnu.io.RXTXPort.readArray(Native Method) at gnu.io.RXTXPort$SerialInputStream.read(RXTXPort.java:1454) - locked <0x88ca55b8> (a gnu.io.RXTXPort$SerialInputStream) at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:411) at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) - locked <0x88cab378> (a java.io.InputStreamReader) at java.io.InputStreamReader.read(InputStreamReader.java:167) at java.io.BufferedReader.fill(BufferedReader.java:136) at java.io.BufferedReader.readLine(BufferedReader.java:299) - locked <0x88cab378> (a java.io.InputStreamReader) at java.io.BufferedReader.readLine(BufferedReader.java:362) at qms.TSerialPort$SerialRead.run(TSerialPort.java:268) at java.lang.Thread.run(Thread.java:595) "Thread-1" prio=1 tid=0x08a43360 nid=0x3c8a runnable [0xb1ac4000..0xb1ac4db0] at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1641) "AWT-XAWT" daemon prio=1 tid=0x08acc848 nid=0x3c87 runnable [0xb1b45000..0xb1b45e30] at sun.awt.X11.XToolkit.waitForEvents(Native Method) at sun.awt.X11.XToolkit.run(XToolkit.java:463) at sun.awt.X11.XToolkit.run(XToolkit.java:438) at java.lang.Thread.run(Thread.java:595) "Java2D Disposer" daemon prio=1 tid=0x08ab9d30 nid=0x3c86 in Object.wait() [0xb1bc6000..0xb1bc70b0] at java.lang.Object.wait(Native Method) - waiting on <0x8917b110> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:116) - locked <0x8917b110> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:132) at sun.java2d.Disposer.run(Disposer.java:107) at java.lang.Thread.run(Thread.java:595) "Low Memory Detector" daemon prio=1 tid=0x087bea68 nid=0x3c84 runnable [0x00000000..0x00000000] "CompilerThread0" daemon prio=1 tid=0x087bd4c0 nid=0x3c83 waiting on condition [0x00000000..0xb23a7a18] "Signal Dispatcher" daemon prio=1 tid=0x087bc520 nid=0x3c82 runnable [0x00000000..0x00000000] "Finalizer" daemon prio=1 tid=0x087b5710 nid=0x3c81 in Object.wait() [0xb26a9000..0xb26a9f30] at java.lang.Object.wait(Native Method) - waiting on <0x8914a770> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:116) - locked <0x8914a770> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:132) at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159) "Reference Handler" daemon prio=1 tid=0x087b49c8 nid=0x3c80 in Object.wait() [0xb272a000..0xb272adb0] at java.lang.Object.wait(Native Method) - waiting on <0x8914a7f0> (a java.lang.ref.Reference$Lock) at java.lang.Object.wait(Object.java:474) at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116) - locked <0x8914a7f0> (a java.lang.ref.Reference$Lock) "main" prio=1 tid=0x08777b88 nid=0x3c7e runnable [0xbffa7000..0xbffa74f8] at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1248) at qms.TSerialPort.Transmit(TSerialPort.java:192) - locked <0x88c99a68> (a qms.TSerialPort) at qms.TIOBoard.GetIOBoardVersion(TIOBoard.java:168) at qms.TIOBoard.(TIOBoard.java:73) at qms.TQMS.(TQMS.java:47) at qms.MainForm.(MainForm.java:2076) at qms.MainForm.main(MainForm.java:2099) "VM Thread" prio=1 tid=0x087b1e20 nid=0x3c7f runnable "VM Periodic Task Thread" prio=1 tid=0x087bff50 nid=0x3c85 waiting on condition -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090403/20b7bca4/attachment-0007.html From Martin.Oberhuber at windriver.com Fri Apr 3 16:23:43 2009 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Sat, 4 Apr 2009 00:23:43 +0200 Subject: [Rxtx] Missing documentation In-Reply-To: <49D5973E.4050400@bbs.darktech.org> References: <49D43979.4050702@bbs.darktech.org> <49D5973E.4050400@bbs.darktech.org> Message-ID: <460801A4097E3D4CA04CC64EE648584809C8BD6F@ism-mail03.corp.ad.wrs.com> Hello Gili, The classes in the gnu.io namespace are designed to work exactly as their counterparts in the javax.comm namespace. Therefore, if you just take the javax.comm Javadocs that's what you want. Unfortunately I don't think we can just copy & paste the javax.comm Javadocs into RXTX due to license restrictions. I guess that's the main reason why RXTX is not (yet) Javadoc'd as extensively as it should be. Actually, writing Javadocs from scratch WITHOUT referencing the wording of the Sun Javadocs is not that easy. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of cowwoc > Sent: Freitag, 03. April 2009 06:58 > To: rxtx at qbang.org > Subject: [Rxtx] Missing documentation > > Hi, > > I noticed that RXTX 2.1 drops javax.comm support in favor > of gnu.io. > I have one major problem with this: the gui.io.* > documentation is very > poor. Many classes and methods have no Javadoc at all which > makes them > difficult to use. Please fix this for the final release. > > Thank you, > Gili > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Fri Apr 3 16:54:50 2009 From: netbeans at gatworks.com (U. George) Date: Fri, 03 Apr 2009 18:54:50 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: <49D546F8.20807@gatworks.com> Message-ID: <49D693BA.8060909@gatworks.com> I would have tried 2 or 3 "^\" . If things are stuck, then all will be at same 'java' instruction. If thread is moving, then one of the snapshots would be different. I *think* flushing/draining wont return until the kernel buffers to device have been accepted by device. Stuck/paused device? Bill Johnson wrote: > > > > > When perceived runability is hung, try a ^\ ( control \) on console. > This gets the JVM to dump the stacks of all the java threads. > > > Good idea... A thread dump is below, it looks like only some system > threads are in wait state which is prob From cowwoc at bbs.darktech.org Fri Apr 3 17:45:09 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Fri, 03 Apr 2009 19:45:09 -0400 Subject: [Rxtx] Missing documentation In-Reply-To: <460801A4097E3D4CA04CC64EE648584809C8BD6F@ism-mail03.corp.ad.wrs.com> References: <49D43979.4050702@bbs.darktech.org> <49D5973E.4050400@bbs.darktech.org> <460801A4097E3D4CA04CC64EE648584809C8BD6F@ism-mail03.corp.ad.wrs.com> Message-ID: <49D69F85.3030804@bbs.darktech.org> You could always send Sun a formal email and ask for permission to copy their Javadoc. I doubt they would give you problems. Gili Oberhuber, Martin wrote: > Hello Gili, > > The classes in the gnu.io namespace are designed to work exactly > as their counterparts in the javax.comm namespace. Therefore, > if you just take the javax.comm Javadocs that's what you want. > > Unfortunately I don't think we can just copy & paste the > javax.comm Javadocs into RXTX due to license restrictions. > > I guess that's the main reason why RXTX is not (yet) Javadoc'd > as extensively as it should be. Actually, writing Javadocs > from scratch WITHOUT referencing the wording of the Sun > Javadocs is not that easy. > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] >> On Behalf Of cowwoc >> Sent: Freitag, 03. April 2009 06:58 >> To: rxtx at qbang.org >> Subject: [Rxtx] Missing documentation >> >> Hi, >> >> I noticed that RXTX 2.1 drops javax.comm support in favor >> of gnu.io. >> I have one major problem with this: the gui.io.* >> documentation is very >> poor. Many classes and methods have no Javadoc at all which >> makes them >> difficult to use. Please fix this for the final release. >> >> Thank you, >> Gili >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> From cowwoc at bbs.darktech.org Sat Apr 4 15:13:38 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sat, 04 Apr 2009 17:13:38 -0400 Subject: [Rxtx] Java5 support Message-ID: <49D7CD82.1040904@bbs.darktech.org> Now that you dropped javax.comm support, how about improving the API by replacing Enumation by Iterator, int by enum, and using Generics? It would improve the usability of the API. Gili From cowwoc at bbs.darktech.org Sat Apr 4 16:12:13 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sat, 04 Apr 2009 18:12:13 -0400 Subject: [Rxtx] RXTX Version mismatch in 2.2pre2 Message-ID: <49D7DB3D.5040008@bbs.darktech.org> When using RXTX-2.2pre2 I always get the following message: WARNING: RXTX Version mismatch Jar version = RXTX-2.2pre1 native lib Version = RXTX-2.2pre2 I have double checked that I am using the correct Jar file. Is this a known bug in pre2? Gili From tjarvi at qbang.org Sat Apr 4 16:48:53 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Apr 2009 16:48:53 -0600 (MDT) Subject: [Rxtx] RXTX Version mismatch in 2.2pre2 In-Reply-To: <49D7DB3D.5040008@bbs.darktech.org> References: <49D7DB3D.5040008@bbs.darktech.org> Message-ID: > When using RXTX-2.2pre2 I always get the following message: > > WARNING: RXTX Version mismatch > Jar version = RXTX-2.2pre1 > native lib Version = RXTX-2.2pre2 > Yep. You should still be able to test it. -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Sat Apr 4 16:50:43 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sat, 04 Apr 2009 18:50:43 -0400 Subject: [Rxtx] RXTX Version mismatch in 2.2pre2 In-Reply-To: References: <49D7DB3D.5040008@bbs.darktech.org> Message-ID: <49D7E443.9070404@bbs.darktech.org> In other words this is a known bug that will be fixed in the final version? Gili Trent Jarvi wrote: > > >> When using RXTX-2.2pre2 I always get the following message: >> >> WARNING: RXTX Version mismatch >> Jar version = RXTX-2.2pre1 >> native lib Version = RXTX-2.2pre2 >> > > Yep. > > You should still be able to test it. > > -- > Trent Jarvi > tjarvi at qbang.org From cowwoc at bbs.darktech.org Sat Apr 4 16:57:34 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sat, 04 Apr 2009 18:57:34 -0400 Subject: [Rxtx] IOException: Underlying input stream returned zero bytes Message-ID: <49D7E5DE.2050405@bbs.darktech.org> Hi, There seems to be a bug in RXTX 2.2pre2's handling of InputStream timeouts. If you open a serial port without ever invoking enableReceiveTimeout() then invoking InputStream.read() will always return 0 bytes right away. If you wrap the InputStream and invoke BufferedReader.readline() you will get the following exception: java.io.IOException: Underlying input stream returned zero bytes at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:268) [na:1.6.0_14-ea] at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:306) [na:1.6.0_14-ea] at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:158) [na:1.6.0_14-ea] at java.io.InputStreamReader.read(InputStreamReader.java:167) [na:1.6.0_14-ea] at java.io.BufferedReader.fill(BufferedReader.java:136) [na:1.6.0_14-ea] at java.io.BufferedReader.readLine(BufferedReader.java:299) [na:1.6.0_14-ea] at java.io.BufferedReader.readLine(BufferedReader.java:362) [na:1.6.0_14-ea] [snip] If you enable a timeout, the exception will only occur after the timeout expires. In short, it looks like RXTX is using a default timeout of zero (I am expecting it to block forever). It looks like other people have run into this as well: http://forums.sun.com/thread.jspa?threadID=5165346&start=10&tstart=0 Please confirm whether this is a known bug. Thank you, Gili From tjarvi at qbang.org Sat Apr 4 17:27:19 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Apr 2009 17:27:19 -0600 (MDT) Subject: [Rxtx] IOException: Underlying input stream returned zero bytes In-Reply-To: <49D7E5DE.2050405@bbs.darktech.org> References: <49D7E5DE.2050405@bbs.darktech.org> Message-ID: On Sat, 4 Apr 2009, cowwoc wrote: > Hi, > > There seems to be a bug in RXTX 2.2pre2's handling of InputStream > timeouts. If you open a serial port without ever invoking > enableReceiveTimeout() then invoking InputStream.read() will always > return 0 bytes right away. If you wrap the InputStream and invoke > BufferedReader.readline() you will get the following exception: > > java.io.IOException: Underlying input stream returned zero bytes > at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:268) > [na:1.6.0_14-ea] > at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:306) > [na:1.6.0_14-ea] > at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:158) > [na:1.6.0_14-ea] > at java.io.InputStreamReader.read(InputStreamReader.java:167) > [na:1.6.0_14-ea] > at java.io.BufferedReader.fill(BufferedReader.java:136) > [na:1.6.0_14-ea] > at java.io.BufferedReader.readLine(BufferedReader.java:299) > [na:1.6.0_14-ea] > at java.io.BufferedReader.readLine(BufferedReader.java:362) > [na:1.6.0_14-ea] > [snip] > > If you enable a timeout, the exception will only occur after the > timeout expires. In short, it looks like RXTX is using a default timeout > of zero (I am expecting it to block forever). It looks like other people > have run into this as well: > http://forums.sun.com/thread.jspa?threadID=5165346&start=10&tstart=0 > > Please confirm whether this is a known bug. > Hi Gili I've known about it but was not sure if it was a bug or not. It looks like we can treat it as a bug if nio is throwing an exception. Timeout and Thresholds are well documented in javax.comm but I didn't recall seeing defaults. For that reason, I've encouraged people to set the threshold and timeout to what they expect. Another note about InputStream.read(void): I noticed that I don't use that function at all while looking at code coverage results. Keep your eye out for additional issues. -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Sat Apr 4 19:03:29 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sat, 04 Apr 2009 21:03:29 -0400 Subject: [Rxtx] IOException: Underlying input stream returned zero bytes In-Reply-To: References: <49D7E5DE.2050405@bbs.darktech.org> Message-ID: <49D80361.7020801@bbs.darktech.org> Trent Jarvi wrote: > For that reason, I've encouraged people to set the threshold and timeout > to what they expect. It doesn't help. There doesn't seem to be a way to disable the timeout, even if you invoke disableReceiveTimeout() explicitly. Let me know when you put in a fix and I will test it. Thanks, Gili From cowwoc at bbs.darktech.org Sat Apr 4 23:27:25 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 01:27:25 -0400 Subject: [Rxtx] Crash in termios.c:892 Message-ID: <49D8413D.7040105@bbs.darktech.org> I can reproduce a crash in RXTX 2.2 pre2 100% of the time using my application code, but I can't seem to bring it down to a minimal testcase. Here is what I see: - thread begins running - open com1 - close com1 - open com5 - leave com5 open - thread shuts down - repeat the same process in a new thread - crash occurs when trying to open com1. Crash disappears if I close() com5 in the previous thread. The output window contains the following: # # A fatal error has been detected by the Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x05475cf6, pid=6064, tid=5436 # # JRE version: 6.0_14-b04 # Java VM: Java HotSpot(TM) Client VM (14.0-b13 mixed mode, sharing windows-x86 ) # Problematic frame: # C [rxtxSerial.dll+0x5cf6] # # An error report file with more information is saved as: # C:\Users\Gili\Documents\foobar\source\hs_err_pid6064.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp Error 0x5 at ..\src\termios.c(892): Access is denied. # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # Please let me know if the crash dump is enough to track down this bug. Thank you, Gili -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: hs_err_pid6064.log Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20090405/7133a1ce/attachment-0004.pl From cowwoc at bbs.darktech.org Sun Apr 5 00:24:19 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 02:24:19 -0400 Subject: [Rxtx] SerialPort.getName() is wrong Message-ID: <49D84E93.7050606@bbs.darktech.org> Sorry for all these emails but I keep on running into more issues. Here is what I noticed: - CommPortIdentifier.getPortIdentifier("COM5") returns a CommPortIdentifier where getName() == "COM5" - If, however, you invoke CommPortIdentifier.open() you get back a SerialPort where SerialPort.getName() is "//./COM5" I am expecting the name to remain consistent. "//./COM5" looks like an implementation detail and (as far as I can tell) it can't be used as an argument for any API method so it is somewhat useless. If getName() were to return "COM5" I could at least use it to get back the original CommPortIdentifier or compare against "known names" such as "COMx" or "LPTx". What do you think? Gili From tjarvi at qbang.org Sun Apr 5 10:18:42 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Apr 2009 10:18:42 -0600 (MDT) Subject: [Rxtx] SerialPort.getName() is wrong In-Reply-To: <49D84E93.7050606@bbs.darktech.org> References: <49D84E93.7050606@bbs.darktech.org> Message-ID: On Sun, 5 Apr 2009, cowwoc wrote: > > Sorry for all these emails but I keep on running into more issues. > Here is what I noticed: > > - CommPortIdentifier.getPortIdentifier("COM5") returns a > CommPortIdentifier where getName() == "COM5" > - If, however, you invoke CommPortIdentifier.open() you get back a > SerialPort where SerialPort.getName() is "//./COM5" > > I am expecting the name to remain consistent. "//./COM5" looks like > an implementation detail and (as far as I can tell) it can't be used as > an argument for any API method so it is somewhat useless. If getName() > were to return "COM5" I could at least use it to get back the original > CommPortIdentifier or compare against "known names" such as "COMx" or > "LPTx". What do you think? > Sure. If it itches enough you should be able to fix this in RXTXCommDriver.java. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Apr 5 10:27:58 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Apr 2009 10:27:58 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D8413D.7040105@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> Message-ID: On Sun, 5 Apr 2009, cowwoc wrote: > > I can reproduce a crash in RXTX 2.2 pre2 100% of the time using my > application code, but I can't seem to bring it down to a minimal testcase. > Here is what I see: > > - thread begins running > - open com1 > - close com1 > - open com5 > - leave com5 open > - thread shuts down > - repeat the same process in a new thread > - crash occurs when trying to open com1. Crash disappears if I close() com5 > in the previous thread. > > The output window contains the following: > > # > # A fatal error has been detected by the Java Runtime Environment: > # > # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x05475cf6, pid=6064, > tid=5436 > # > # JRE version: 6.0_14-b04 > # Java VM: Java HotSpot(TM) Client VM (14.0-b13 mixed mode, sharing > windows-x86 ) > # Problematic frame: > # C [rxtxSerial.dll+0x5cf6] > # > # An error report file with more information is saved as: > # C:\Users\Gili\Documents\foobar\source\hs_err_pid6064.log > # > # If you would like to submit a bug report, please visit: > # http://java.sun.com/webapps/bugreport/crash.jsp > Error 0x5 at ..\src\termios.c(892): Access is denied. > > > # The crash happened outside the Java Virtual Machine in native code. > # See problematic frame for where to report the bug. > # > > Please let me know if the crash dump is enough to track down this bug. > Hi Gili, You are responsible for cleaning up the serial ports when using threads. That said, if the thread did shut down, finalize should have been called if you are not passing the object around. See RXTXPort.java. protected void finalize() { if (debug) z.reportln( "RXTXPort:finalize()"); if( fd > 0 ) { if (debug) z.reportln( "RXTXPort:calling close()"); close(); } z.finalize(); } The exception is interesting. This is on Vista? Usually it just gives an open error when another process has the port. -- Trent Jarvi tjarvi at mathworks.com From cowwoc at bbs.darktech.org Sun Apr 5 10:35:55 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 12:35:55 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: References: <49D8413D.7040105@bbs.darktech.org> Message-ID: <49D8DDEB.5010908@bbs.darktech.org> Trent Jarvi wrote: > You are responsible for cleaning up the serial ports when using threads. > That said, if the thread did shut down, finalize should have been called > if you are not passing the object around. See RXTXPort.java. > > protected void finalize() > { > if (debug) > z.reportln( "RXTXPort:finalize()"); > if( fd > 0 ) > { > if (debug) > z.reportln( "RXTXPort:calling close()"); > close(); > } > z.finalize(); > } Two points: 1) One should never rely on finalizers because they may never run. 2) RXTX shouldn't cause the entire JVM to crash if I misuse the API. The native code should recover more gracefully. > The exception is interesting. This is on Vista? Usually it just gives > an open error when another process has the port. Yes, this is on Vista 64-bit. I'd really like to see this bug fixed. Is this code compilable under Visual Studio? If so, I can debug the problem on my end and send you a patch. Thanks, Gili From cowwoc at bbs.darktech.org Sun Apr 5 10:36:20 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 12:36:20 -0400 Subject: [Rxtx] SerialPort.getName() is wrong In-Reply-To: References: <49D84E93.7050606@bbs.darktech.org> Message-ID: <49D8DE04.6030306@bbs.darktech.org> Trent Jarvi wrote: >> I am expecting the name to remain consistent. "//./COM5" looks like >> an implementation detail and (as far as I can tell) it can't be used as >> an argument for any API method so it is somewhat useless. If getName() >> were to return "COM5" I could at least use it to get back the original >> CommPortIdentifier or compare against "known names" such as "COMx" or >> "LPTx". What do you think? >> > > Sure. > > If it itches enough you should be able to fix this in RXTXCommDriver.java. I'm not sure I understand. Are you saying that if I submit a patch you will commit it? Gili From tjarvi at qbang.org Sun Apr 5 10:46:23 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Apr 2009 10:46:23 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D8DDEB.5010908@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> Message-ID: On Sun, 5 Apr 2009, cowwoc wrote: > Trent Jarvi wrote: >> You are responsible for cleaning up the serial ports when using threads. >> That said, if the thread did shut down, finalize should have been called if >> you are not passing the object around. See RXTXPort.java. >> >> protected void finalize() >> { >> if (debug) >> z.reportln( "RXTXPort:finalize()"); >> if( fd > 0 ) >> { >> if (debug) >> z.reportln( "RXTXPort:calling close()"); >> close(); >> } >> z.finalize(); >> } > > Two points: > > 1) One should never rely on finalizers because they may never run. > 2) RXTX shouldn't cause the entire JVM to crash if I misuse the API. The > native code should recover more gracefully. > >> The exception is interesting. This is on Vista? Usually it just gives an >> open error when another process has the port. > > Yes, this is on Vista 64-bit. I'd really like to see this bug fixed. > Is this code compilable under Visual Studio? If so, I can debug the problem > on my end and send you a patch. > It will compile with the msvc cl.exe and nmake. See Makefile.msvc in the top level directory. You will need to adjust the JAVA_HOME variable. Also use the MSVC command prompt for x86_64 so cl and nmake are on your path. All the best, -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Apr 5 10:49:10 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Apr 2009 10:49:10 -0600 (MDT) Subject: [Rxtx] SerialPort.getName() is wrong In-Reply-To: <49D8DE04.6030306@bbs.darktech.org> References: <49D84E93.7050606@bbs.darktech.org> <49D8DE04.6030306@bbs.darktech.org> Message-ID: On Sun, 5 Apr 2009, cowwoc wrote: > Trent Jarvi wrote: >>> I am expecting the name to remain consistent. "//./COM5" looks like >>> an implementation detail and (as far as I can tell) it can't be used as >>> an argument for any API method so it is somewhat useless. If getName() >>> were to return "COM5" I could at least use it to get back the original >>> CommPortIdentifier or compare against "known names" such as "COMx" or >>> "LPTx". What do you think? >>> >> >> Sure. >> >> If it itches enough you should be able to fix this in RXTXCommDriver.java. > > I'm not sure I understand. Are you saying that if I submit a patch > you will commit it? > Hi Gili, Post a patch here and if nobody complains, we will commit it and give you credit. Yep. Other issues like changing the API to use java5 that may break existing apps are likely to run into objections but bug fixes usually get fixed just as you mention. -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Sun Apr 5 10:55:07 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 12:55:07 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> Message-ID: <49D8E26B.2040705@bbs.darktech.org> Trent Jarvi wrote: > It will compile with the msvc cl.exe and nmake. See Makefile.msvc in > the top level directory. You will need to adjust the JAVA_HOME > variable. Also use the MSVC command prompt for x86_64 so cl and nmake > are on your path. This is very odd. The CVS version of the code does not contain this file. Do you keep the latest code somewhere else? Gili From cowwoc at bbs.darktech.org Sun Apr 5 11:01:58 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 13:01:58 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D8E26B.2040705@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> Message-ID: <49D8E406.10708@bbs.darktech.org> cowwoc wrote: > Trent Jarvi wrote: >> It will compile with the msvc cl.exe and nmake. See Makefile.msvc in >> the top level directory. You will need to adjust the JAVA_HOME >> variable. Also use the MSVC command prompt for x86_64 so cl and nmake >> are on your path. > > This is very odd. The CVS version of the code does not contain this > file. Do you keep the latest code somewhere else? Okay I figured it out. CVS head is out of date, the "commapi-0-0-1" revision contains the correct files. Gili From tjarvi at qbang.org Sun Apr 5 11:05:43 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Apr 2009 11:05:43 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D8E26B.2040705@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> Message-ID: CVS HEAD is currently the rxtx 2.0 code. A branch was created long ago for 'experimental' gnu.io work. It just happens that the branch is what everyone uses now. checkout -r commapi-0-0-1 rxtx-devel will get the branch On Sun, 5 Apr 2009, cowwoc wrote: > Trent Jarvi wrote: >> It will compile with the msvc cl.exe and nmake. See Makefile.msvc in the >> top level directory. You will need to adjust the JAVA_HOME variable. Also >> use the MSVC command prompt for x86_64 so cl and nmake are on your path. > > This is very odd. The CVS version of the code does not contain this > file. Do you keep the latest code somewhere else? > > Gili > From cowwoc at bbs.darktech.org Sun Apr 5 14:50:47 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 16:50:47 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> Message-ID: <49D919A7.1070806@bbs.darktech.org> Okay, I tracked down the crash. It's being caused by YACK() using a 80-character buffer. The error message is longer than 80 characters, so _snprintf_s() crashes to avoid a buffer overflow. Please apply the attached patch and add the zipped up Visual Studio project directory. It's not perfect yet but it's a good start. Gili Trent Jarvi wrote: > > CVS HEAD is currently the rxtx 2.0 code. A branch was created long > ago for 'experimental' gnu.io work. It just happens that the branch > is what everyone uses now. > > checkout -r commapi-0-0-1 rxtx-devel > > will get the branch > > On Sun, 5 Apr 2009, cowwoc wrote: > >> Trent Jarvi wrote: >>> It will compile with the msvc cl.exe and nmake. See Makefile.msvc >>> in the top level directory. You will need to adjust the JAVA_HOME >>> variable. Also use the MSVC command prompt for x86_64 so cl and >>> nmake are on your path. >> >> This is very odd. The CVS version of the code does not contain >> this file. Do you keep the latest code somewhere else? >> >> Gili >> -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx-devel.patch Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20090405/d9b82962/attachment-0003.pl -------------- next part -------------- A non-text attachment was scrubbed... Name: Win32.zip Type: application/octet-stream Size: 17764 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20090405/d9b82962/attachment-0005.obj From cowwoc at bbs.darktech.org Sun Apr 5 15:22:01 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 17:22:01 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D919A7.1070806@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> <49D919A7.1070806@bbs.darktech.org> Message-ID: <49D920F9.6080702@bbs.darktech.org> My mistake. The problem in YACK is real, but it isn't the real cause of the crash. The crash is caused by termios.c line 1099: index->prev->next = port; because in my case "index->prev==0". I think the bug is that the code assumes that index will contain a minimum of two entries if we're inserting a previously closed fd. In my case, it only contains one. I'm not sure why you have this code branch (as opposed to appending to the end of index). Please take a look. Thanks, Gili cowwoc wrote: > > Okay, I tracked down the crash. It's being caused by YACK() using a > 80-character buffer. The error message is longer than 80 characters, so > _snprintf_s() crashes to avoid a buffer overflow. > > Please apply the attached patch and add the zipped up Visual Studio > project directory. It's not perfect yet but it's a good start. > > Gili > > Trent Jarvi wrote: >> >> CVS HEAD is currently the rxtx 2.0 code. A branch was created long >> ago for 'experimental' gnu.io work. It just happens that the branch >> is what everyone uses now. >> >> checkout -r commapi-0-0-1 rxtx-devel >> >> will get the branch >> >> On Sun, 5 Apr 2009, cowwoc wrote: >> >>> Trent Jarvi wrote: >>>> It will compile with the msvc cl.exe and nmake. See Makefile.msvc >>>> in the top level directory. You will need to adjust the JAVA_HOME >>>> variable. Also use the MSVC command prompt for x86_64 so cl and >>>> nmake are on your path. >>> >>> This is very odd. The CVS version of the code does not contain >>> this file. Do you keep the latest code somewhere else? >>> >>> Gili >>> From tjarvi at qbang.org Sun Apr 5 16:13:27 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Apr 2009 16:13:27 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D920F9.6080702@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> <49D919A7.1070806@bbs.darktech.org> <49D920F9.6080702@bbs.darktech.org> Message-ID: Hi Gili, Are you using the cvs version? I thought we fixed the linked list issues. A solution was posted to the list. Let me look at work tomorrow to see what I have. On Sun, 5 Apr 2009, cowwoc wrote: > > My mistake. The problem in YACK is real, but it isn't the real cause > of the crash. The crash is caused by termios.c line 1099: > > index->prev->next = port; > > because in my case "index->prev==0". I think the bug is that the code > assumes that index will contain a minimum of two entries if we're inserting a > previously closed fd. In my case, it only contains one. > > I'm not sure why you have this code branch (as opposed to appending > to the end of index). Please take a look. > > Thanks, > Gili > > cowwoc wrote: >> >> Okay, I tracked down the crash. It's being caused by YACK() using a >> 80-character buffer. The error message is longer than 80 characters, so >> _snprintf_s() crashes to avoid a buffer overflow. >> >> Please apply the attached patch and add the zipped up Visual Studio >> project directory. It's not perfect yet but it's a good start. >> >> Gili >> >> Trent Jarvi wrote: >>> >>> CVS HEAD is currently the rxtx 2.0 code. A branch was created long ago >>> for 'experimental' gnu.io work. It just happens that the branch is what >>> everyone uses now. >>> >>> checkout -r commapi-0-0-1 rxtx-devel >>> >>> will get the branch >>> >>> On Sun, 5 Apr 2009, cowwoc wrote: >>> >>>> Trent Jarvi wrote: >>>>> It will compile with the msvc cl.exe and nmake. See Makefile.msvc in >>>>> the top level directory. You will need to adjust the JAVA_HOME >>>>> variable. Also use the MSVC command prompt for x86_64 so cl and nmake >>>>> are on your path. >>>> >>>> This is very odd. The CVS version of the code does not contain this >>>> file. Do you keep the latest code somewhere else? >>>> >>>> Gili >>>> > From ilkka at myller.com Sun Apr 5 23:58:08 2009 From: ilkka at myller.com (Ilkka Myller) Date: Mon, 6 Apr 2009 08:58:08 +0300 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> <49D919A7.1070806@bbs.darktech.org> <49D920F9.6080702@bbs.darktech.org> Message-ID: <19779C97-E0C7-4E3D-B715-F84F50F00CE6@myller.com> Hi all, I've already submitted the patch to fix this issue in february: http://mailman.qbang.org/pipermail/rxtx/2009-February/3989441.html The patch fixes the mentioned doubly linked list handling in termios.c -- I Trent Jarvi kirjoitti 6.4.2009 kello 1.13: > > Hi Gili, > > Are you using the cvs version? I thought we fixed the linked list > issues. > A solution was posted to the list. Let me look at work tomorrow to > see > what I have. > > > > On Sun, 5 Apr 2009, cowwoc wrote: > >> >> My mistake. The problem in YACK is real, but it isn't the real cause >> of the crash. The crash is caused by termios.c line 1099: >> >> index->prev->next = port; >> >> because in my case "index->prev==0". I think the bug is that the >> code >> assumes that index will contain a minimum of two entries if we're >> inserting a >> previously closed fd. In my case, it only contains one. >> >> I'm not sure why you have this code branch (as opposed to appending >> to the end of index). Please take a look. >> >> Thanks, >> Gili >> >> cowwoc wrote: >>> >>> Okay, I tracked down the crash. It's being caused by YACK() >>> using a >>> 80-character buffer. The error message is longer than 80 >>> characters, so >>> _snprintf_s() crashes to avoid a buffer overflow. >>> >>> Please apply the attached patch and add the zipped up Visual >>> Studio >>> project directory. It's not perfect yet but it's a good start. >>> >>> Gili >>> >>> Trent Jarvi wrote: >>>> >>>> CVS HEAD is currently the rxtx 2.0 code. A branch was created >>>> long ago >>>> for 'experimental' gnu.io work. It just happens that the branch >>>> is what >>>> everyone uses now. >>>> >>>> checkout -r commapi-0-0-1 rxtx-devel >>>> >>>> will get the branch >>>> >>>> On Sun, 5 Apr 2009, cowwoc wrote: >>>> >>>>> Trent Jarvi wrote: >>>>>> It will compile with the msvc cl.exe and nmake. See >>>>>> Makefile.msvc in >>>>>> the top level directory. You will need to adjust the JAVA_HOME >>>>>> variable. Also use the MSVC command prompt for x86_64 so cl and >>>>>> nmake >>>>>> are on your path. >>>>> >>>>> This is very odd. The CVS version of the code does not >>>>> contain this >>>>> file. Do you keep the latest code somewhere else? >>>>> >>>>> Gili >>>>> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Steffen.DETTMER at ingenico.com Mon Apr 6 02:53:47 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 6 Apr 2009 10:53:47 +0200 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D919A7.1070806@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> <49D919A7.1070806@bbs.darktech.org> Message-ID: <20090406085347.GM8289@elberon.bln.de.ingenico.com> Hi, just two minor details, first about the errno change, I though #include extern int errno; is correct (POSIX.1) - why this change? second about the log message, I think the maximum length could be limited and the return value of malloc must be checked for != NULL before using. Should it be _snprintf_s( message, 80, _TRUNCATE, "Error 0x%x at %s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); (I know that MS-CRT _snprintf does not guarantee to have a final EOS, but I think _snprintf_s with _TRUNCATE does so?). If it is known that truncation may happen maybe sizeof[message] could be increased; maybe using some %.20s could be used avoiding __FILE__ including big pathes to a message where all the message had been cut-off. To have it portable I think it could be: /* generally: */ #if defined(_MSC_VER) # define snprintf _snprintf #endif snprintf(message, sizeof(message), "Error 0x%x at %.20s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); message[sizeof(message)-1] = '\0'; /* needed for MS CRT snprintf */ (for length and size parameter I think size_t could be an option, but on several platforms, including MS-CRT and older glibc, there is no %z, unfortunately) oki, Steffen * cowwoc wrote on Sun, Apr 05, 2009 at 16:50 -0400: > > Okay, I tracked down the crash. It's being caused by YACK() using a > 80-character buffer. The error message is longer than 80 characters, so > _snprintf_s() crashes to avoid a buffer overflow. > > Please apply the attached patch and add the zipped up Visual Studio > project directory. It's not perfect yet but it's a good start. > > Gili > > Trent Jarvi wrote: > > > >CVS HEAD is currently the rxtx 2.0 code. A branch was created long > >ago for 'experimental' gnu.io work. It just happens that the branch > >is what everyone uses now. > > > >checkout -r commapi-0-0-1 rxtx-devel > > > >will get the branch > > > >On Sun, 5 Apr 2009, cowwoc wrote: > > > >>Trent Jarvi wrote: > >>>It will compile with the msvc cl.exe and nmake. See Makefile.msvc > >>>in the top level directory. You will need to adjust the JAVA_HOME > >>>variable. Also use the MSVC command prompt for x86_64 so cl and > >>>nmake are on your path. > >> > >> This is very odd. The CVS version of the code does not contain > >>this file. Do you keep the latest code somewhere else? > >> > >>Gili > >> > Index: ParallelImp.c > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/ParallelImp.c,v > retrieving revision 1.15.2.36 > diff -u -r1.15.2.36 ParallelImp.c > --- ParallelImp.c 11 Feb 2009 01:04:19 -0000 1.15.2.36 > +++ ParallelImp.c 5 Apr 2009 17:55:23 -0000 > @@ -119,7 +119,7 @@ > # include > #endif > > -extern int errno; > +_CRTIMP extern int * __cdecl _errno(void); > > #include "ParallelImp.h" > > @@ -181,8 +181,6 @@ > > #if defined (WIN32) > > -#define CTL_CODE( DeviceType, Function, Method, Access ) (((DeviceType) << 16) | ((Access) << 14) | ((Function) << 2) | (Method)) > - > #define FILE_DEVICE_PARALLEL_PORT 0x00000016 > #define METHOD_BUFFERED 0 > #define FILE_ANY_ACCESS 0 > @@ -253,7 +251,6 @@ > jobject jobj) > { > int fd = get_java_var( env, jobj,"fd","I" ); > - int status; > #if defined (__linux__) > ioctl(fd, LPGETSTATUS, &status); > #elif defined (WIN32) > Index: SerialImp.c > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v > retrieving revision 1.46.2.203 > diff -u -r1.46.2.203 SerialImp.c > --- SerialImp.c 19 Mar 2009 03:27:48 -0000 1.46.2.203 > +++ SerialImp.c 5 Apr 2009 17:49:48 -0000 > @@ -147,7 +147,7 @@ > #include > #endif /* LIBLOCKDEV */ > > -extern int errno; > +_CRTIMP extern int * __cdecl _errno(void); > > #include "SerialImp.h" > > Index: termios.c > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/termios.c,v > retrieving revision 1.9.2.62 > diff -u -r1.9.2.62 termios.c > --- termios.c 13 Jan 2009 03:08:55 -0000 1.9.2.62 > +++ termios.c 5 Apr 2009 17:54:09 -0000 > @@ -88,7 +88,7 @@ > #define SIGIO 0 > > int my_errno; > -extern int errno; > +_CRTIMP extern int * __cdecl _errno(void); > struct termios_list > { > char filename[80]; > @@ -1350,7 +1350,7 @@ > In that case use EAGAIN. See SerialImp.c:testRead() > ----------------------------------------------------------*/ > > -int serial_read( int fd, void *vb, int size ) > +int serial_read( int fd, void *vb, unsigned int size ) > { > long start, now; > unsigned long nBytes = 0, total = 0, error; > Index: win32termios.h > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/win32termios.h,v > retrieving revision 1.5.2.34 > diff -u -r1.5.2.34 win32termios.h > --- win32termios.h 5 Feb 2009 01:25:05 -0000 1.5.2.34 > +++ win32termios.h 5 Apr 2009 20:29:30 -0000 > @@ -60,6 +60,7 @@ > #include > #include > #include > +#include > #ifdef TRACE > #define ENTER(x) report("entering "x" \n"); > #define LEAVE(x) report("leaving "x" \n"); > @@ -70,8 +71,9 @@ > #if defined(_MSC_VER) > #define YACK() \ > { \ > - char *allocTextBuf, message[80]; \ > - unsigned long nChars; \ > + char *allocTextBuf, *message; \ > + const unsigned short longestNumber = 20; \ > + unsigned long nChars, len; \ > unsigned int errorCode = GetLastError(); \ > nChars = FormatMessage ( \ > FORMAT_MESSAGE_ALLOCATE_BUFFER | \ > @@ -82,8 +84,12 @@ > (LPSTR)&allocTextBuf, \ > 16, \ > NULL ); \ > - _snprintf_s( message, 80, 80, "Error 0x%x at %s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); \ > + len = strlen("Error 0x") + longestNumber + strlen(" at ") + strlen(__FILE__) + longestNumber + \ > + strlen(": ") + ((nChars+1) * sizeof(TCHAR)) + 1; \ > + message = malloc(len); \ > + _snprintf_s( message, len, len - 1, "Error 0x%x at %s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); \ > report_error( message ); \ > + free(message); \ > LocalFree(allocTextBuf); \ > Sleep(1); \ > } > @@ -173,7 +179,7 @@ > int serial_test( char * ); > int serial_open(const char *File, int flags, ... ); > int serial_close(int fd); > -int serial_read(int fd, void *b, int size); > +int serial_read(int fd, void *b, unsigned int size); > int serial_write(int fd, char *Str, int length); > /* > * lcc winsock.h conflicts > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx End of message. ------------------------------------------------------------------->8======= About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From bill7007 at gmail.com Mon Apr 6 16:34:50 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Mon, 6 Apr 2009 18:34:50 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: <49D693BA.8060909@gatworks.com> References: <49D546F8.20807@gatworks.com> <49D693BA.8060909@gatworks.com> Message-ID: Once it hung, three stack dumps minutes apart were exactly the same. I have a noticed that when it hangs, the read appears after flush() enter and before flush leave() that doesn't happen like: RXTXPort:SerialOutputStream:flush() enter RXTXPort:SerialInputStream:read(8192 0 8192) called When it works, flush() enter and leave happen together. It may just be because flush() hangs and read is the only other thread waiting to run at that point. I don't know much about the RXTX design and kernel interaction, just digging through the code some. Is there a design description somewhere? Am hung up on target system compile since UTS_RELEASE seems no longer defined for 2.6.18 up kernels and have not figured a good patch yet. But, that is another issue. Thanks for the good help. On Fri, Apr 3, 2009 at 6:54 PM, U. George wrote: > I would have tried 2 or 3 "^\" . If things are stuck, then all will be at > same 'java' instruction. If thread is moving, then one of the snapshots > would be different. > > I *think* flushing/draining wont return until the kernel buffers to device > have been accepted by device. Stuck/paused device? > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090406/c4b509d8/attachment-0004.html From tjarvi at qbang.org Mon Apr 6 17:45:38 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 6 Apr 2009 17:45:38 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <20090406085347.GM8289@elberon.bln.de.ingenico.com> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> <49D919A7.1070806@bbs.darktech.org> <20090406085347.GM8289@elberon.bln.de.ingenico.com> Message-ID: The error bits in the patch can probably just be dropped out. I don't see what they solve. Your snprintf define appears to work. The following is what I'd like to put in if noone objects. #if defined(_MSC_VER) # define snprintf _snprintf #endif #define YACK() \ { \ char *allocTextBuf, message[80]; \ unsigned long nChars; \ unsigned int errorCode = GetLastError(); \ nChars = FormatMessage ( \ FORMAT_MESSAGE_ALLOCATE_BUFFER | \ FORMAT_MESSAGE_FROM_SYSTEM, \ NULL, \ errorCode, \ MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT), \ (LPSTR)&allocTextBuf, \ 16, \ NULL ); \ snprintf( message, 80, "Error 0x%x at %s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); \ message[sizeof(message)-1] = '\0'; /* needed for MS CRT snprintf */ \ report_error( message ); \ LocalFree(allocTextBuf); \ Sleep(1); \ } On Mon, 6 Apr 2009, Steffen DETTMER wrote: > Hi, > > just two minor details, first about the errno change, I though > > #include > extern int errno; > > is correct (POSIX.1) - why this change? > > second about the log message, I think the maximum length could be > limited and the return value of malloc must be checked for != > NULL before using. > > Should it be > > _snprintf_s( message, 80, _TRUNCATE, "Error 0x%x at %s(%d): %s\n", > errorCode, __FILE__, __LINE__, allocTextBuf); > > (I know that MS-CRT _snprintf does not guarantee to have a final > EOS, but I think _snprintf_s with _TRUNCATE does so?). > > If it is known that truncation may happen maybe sizeof[message] > could be increased; maybe using some %.20s could be used avoiding > __FILE__ including big pathes to a message where all the message > had been cut-off. > > To have it portable I think it could be: > > /* generally: */ > #if defined(_MSC_VER) > # define snprintf _snprintf > #endif > > snprintf(message, sizeof(message), "Error 0x%x at %.20s(%d): %s\n", > errorCode, __FILE__, __LINE__, allocTextBuf); > message[sizeof(message)-1] = '\0'; /* needed for MS CRT snprintf */ > > (for length and size parameter I think size_t could be an option, > but on several platforms, including MS-CRT and older glibc, > there is no %z, unfortunately) > > oki, > > Steffen > > > * cowwoc wrote on Sun, Apr 05, 2009 at 16:50 -0400: >> >> Okay, I tracked down the crash. It's being caused by YACK() using a >> 80-character buffer. The error message is longer than 80 characters, so >> _snprintf_s() crashes to avoid a buffer overflow. >> >> Please apply the attached patch and add the zipped up Visual Studio >> project directory. It's not perfect yet but it's a good start. >> >> Gili >> >> Trent Jarvi wrote: >> > >> >CVS HEAD is currently the rxtx 2.0 code. A branch was created long >> >ago for 'experimental' gnu.io work. It just happens that the branch >> >is what everyone uses now. >> > >> >checkout -r commapi-0-0-1 rxtx-devel >> > >> >will get the branch >> > >> >On Sun, 5 Apr 2009, cowwoc wrote: >> > >> >>Trent Jarvi wrote: >> >>>It will compile with the msvc cl.exe and nmake. See Makefile.msvc >> >>>in the top level directory. You will need to adjust the JAVA_HOME >> >>>variable. Also use the MSVC command prompt for x86_64 so cl and >> >>>nmake are on your path. >> >> >> >> This is very odd. The CVS version of the code does not contain >> >>this file. Do you keep the latest code somewhere else? >> >> >> >>Gili >> >> > >> Index: ParallelImp.c >> =================================================================== >> RCS file: /usr/local/cvsroot/rxtx-devel/src/ParallelImp.c,v >> retrieving revision 1.15.2.36 >> diff -u -r1.15.2.36 ParallelImp.c >> --- ParallelImp.c 11 Feb 2009 01:04:19 -0000 1.15.2.36 >> +++ ParallelImp.c 5 Apr 2009 17:55:23 -0000 >> @@ -119,7 +119,7 @@ >> # include >> #endif >> >> -extern int errno; >> +_CRTIMP extern int * __cdecl _errno(void); >> >> #include "ParallelImp.h" >> >> @@ -181,8 +181,6 @@ >> >> #if defined (WIN32) >> >> -#define CTL_CODE( DeviceType, Function, Method, Access ) (((DeviceType) << 16) | ((Access) << 14) | ((Function) << 2) | (Method)) >> - >> #define FILE_DEVICE_PARALLEL_PORT 0x00000016 >> #define METHOD_BUFFERED 0 >> #define FILE_ANY_ACCESS 0 >> @@ -253,7 +251,6 @@ >> jobject jobj) >> { >> int fd = get_java_var( env, jobj,"fd","I" ); >> - int status; >> #if defined (__linux__) >> ioctl(fd, LPGETSTATUS, &status); >> #elif defined (WIN32) >> Index: SerialImp.c >> =================================================================== >> RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v >> retrieving revision 1.46.2.203 >> diff -u -r1.46.2.203 SerialImp.c >> --- SerialImp.c 19 Mar 2009 03:27:48 -0000 1.46.2.203 >> +++ SerialImp.c 5 Apr 2009 17:49:48 -0000 >> @@ -147,7 +147,7 @@ >> #include >> #endif /* LIBLOCKDEV */ >> >> -extern int errno; >> +_CRTIMP extern int * __cdecl _errno(void); >> >> #include "SerialImp.h" >> >> Index: termios.c >> =================================================================== >> RCS file: /usr/local/cvsroot/rxtx-devel/src/termios.c,v >> retrieving revision 1.9.2.62 >> diff -u -r1.9.2.62 termios.c >> --- termios.c 13 Jan 2009 03:08:55 -0000 1.9.2.62 >> +++ termios.c 5 Apr 2009 17:54:09 -0000 >> @@ -88,7 +88,7 @@ >> #define SIGIO 0 >> >> int my_errno; >> -extern int errno; >> +_CRTIMP extern int * __cdecl _errno(void); >> struct termios_list >> { >> char filename[80]; >> @@ -1350,7 +1350,7 @@ >> In that case use EAGAIN. See SerialImp.c:testRead() >> ----------------------------------------------------------*/ >> >> -int serial_read( int fd, void *vb, int size ) >> +int serial_read( int fd, void *vb, unsigned int size ) >> { >> long start, now; >> unsigned long nBytes = 0, total = 0, error; >> Index: win32termios.h >> =================================================================== >> RCS file: /usr/local/cvsroot/rxtx-devel/src/win32termios.h,v >> retrieving revision 1.5.2.34 >> diff -u -r1.5.2.34 win32termios.h >> --- win32termios.h 5 Feb 2009 01:25:05 -0000 1.5.2.34 >> +++ win32termios.h 5 Apr 2009 20:29:30 -0000 >> @@ -60,6 +60,7 @@ >> #include >> #include >> #include >> +#include >> #ifdef TRACE >> #define ENTER(x) report("entering "x" \n"); >> #define LEAVE(x) report("leaving "x" \n"); >> @@ -70,8 +71,9 @@ >> #if defined(_MSC_VER) >> #define YACK() \ >> { \ >> - char *allocTextBuf, message[80]; \ >> - unsigned long nChars; \ >> + char *allocTextBuf, *message; \ >> + const unsigned short longestNumber = 20; \ >> + unsigned long nChars, len; \ >> unsigned int errorCode = GetLastError(); \ >> nChars = FormatMessage ( \ >> FORMAT_MESSAGE_ALLOCATE_BUFFER | \ >> @@ -82,8 +84,12 @@ >> (LPSTR)&allocTextBuf, \ >> 16, \ >> NULL ); \ >> - _snprintf_s( message, 80, 80, "Error 0x%x at %s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); \ >> + len = strlen("Error 0x") + longestNumber + strlen(" at ") + strlen(__FILE__) + longestNumber + \ >> + strlen(": ") + ((nChars+1) * sizeof(TCHAR)) + 1; \ >> + message = malloc(len); \ >> + _snprintf_s( message, len, len - 1, "Error 0x%x at %s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); \ >> report_error( message ); \ >> + free(message); \ >> LocalFree(allocTextBuf); \ >> Sleep(1); \ >> } >> @@ -173,7 +179,7 @@ >> int serial_test( char * ); >> int serial_open(const char *File, int flags, ... ); >> int serial_close(int fd); >> -int serial_read(int fd, void *b, int size); >> +int serial_read(int fd, void *b, unsigned int size); >> int serial_write(int fd, char *Str, int length); >> /* >> * lcc winsock.h conflicts >> > > >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > > > > > > > > > > > > End of message. > ------------------------------------------------------------------->8======= > > > About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. > This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > P Please consider the environment before printing this e-mail > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Apr 6 18:11:28 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 6 Apr 2009 18:11:28 -0600 (MDT) Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: <49D546F8.20807@gatworks.com> <49D693BA.8060909@gatworks.com> Message-ID: UTS_RELEASE is defined in now. The check really should be removed from RXTX. It was a defensive check for wilder times when GNU glibc did not have defines the kernel headers had so rxtx would include the kernel headers instead. :/ If you don't have linux/version.h, it is generated when you configure the kernel. make oldconfig used to do the trick. It may make sense to work with the prerelease or CVS code. RXTX just assumes that flush, read and anything else the kernel exposes may be called at anytime from any thread. There isn't a design for the kernel interaction. There are higher level constraints put in Java to prevent some things happening at the same time with 'synchronized.' RXTXPort.java has all of those. When the port is opened, a native event thread is started which uses select to know if an event has happened. BSD like systems have a native thread that fires off on write which tries to flush() to determine when the output buffer is empty asynchronously. The rest is not marshaled in any fashion at the native level. T I think there is a lower level deadlock being triggered in flush as well. I don't think it should be possible if everything was right underneath us. You may want to examine the java code closer to make sure it isnt possible the lock is there. On Mon, 6 Apr 2009, Bill Johnson wrote: > Once it hung, three stack dumps minutes apart were exactly the same. > I have a noticed that when it hangs, the read appears after flush() enter and > before flush leave() that doesn't happen like: > RXTXPort:SerialOutputStream:flush() enter > RXTXPort:SerialInputStream:read(8192 0 8192) called > > When it works, flush() enter and leave happen together. It may just be because > flush() hangs and read is the only other thread waiting to run at that point. > I don't know much about the RXTX design and kernel interaction, just digging > through the code some. Is there a design description somewhere? > > Am hung up on target system compile since UTS_RELEASE seems no longer defined for > 2.6.18 up kernels and have not figured a good patch yet. But, that is another > issue. > > Thanks for the good help. > > > On Fri, Apr 3, 2009 at 6:54 PM, U. George wrote: > I would have tried 2 or 3 "^\" . If things are stuck, then all will be > at same 'java' instruction. If thread is moving, then one of the > snapshots would be different. > > I *think* flushing/draining wont return until the kernel buffers to > device have been accepted by device. Stuck/paused device? > > > > > From tjarvi at qbang.org Mon Apr 6 18:28:50 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 6 Apr 2009 18:28:50 -0600 (MDT) Subject: [Rxtx] CVS updates. Pre3 is comming. Message-ID: I need to go through the bugzilla reports prior to the pre3 release. I think this should be close if you want to check it out from CVS. added: YACK() debug overflow fix for windows Steffen DETTMER (and many others) multiport fix for windows. Ilkka Myller http://mailman.qbang.org/pipermail/rxtx/2009-February/3989441.html I think this code is current. If I missed something, yell. CVS Info: export/setenv CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login # passwd mousy cvs checkout -r commapi-0-0-1 rxtx-devel -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Apr 6 22:32:07 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 6 Apr 2009 22:32:07 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D919A7.1070806@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> <49D919A7.1070806@bbs.darktech.org> Message-ID: Ah. I'll put this in CVS tomorrow. I did sync up the code with my work sandbox today. I just forgot to pull and add this. On Sun, 5 Apr 2009, cowwoc wrote: > > Okay, I tracked down the crash. It's being caused by YACK() using a > 80-character buffer. The error message is longer than 80 characters, so > _snprintf_s() crashes to avoid a buffer overflow. > > Please apply the attached patch and add the zipped up Visual Studio > project directory. It's not perfect yet but it's a good start. > > Gili > > Trent Jarvi wrote: >> >> CVS HEAD is currently the rxtx 2.0 code. A branch was created long ago for >> 'experimental' gnu.io work. It just happens that the branch is what >> everyone uses now. >> >> checkout -r commapi-0-0-1 rxtx-devel >> >> will get the branch >> >> On Sun, 5 Apr 2009, cowwoc wrote: >> >>> Trent Jarvi wrote: >>>> It will compile with the msvc cl.exe and nmake. See Makefile.msvc in the >>>> top level directory. You will need to adjust the JAVA_HOME variable. >>>> Also use the MSVC command prompt for x86_64 so cl and nmake are on your >>>> path. >>> >>> This is very odd. The CVS version of the code does not contain this >>> file. Do you keep the latest code somewhere else? >>> >>> Gili >>> > From cowwoc at bbs.darktech.org Tue Apr 7 06:07:46 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Tue, 07 Apr 2009 08:07:46 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: References: Message-ID: <49DB4212.40807@bbs.darktech.org> > just two minor details, first about the errno change, I though > > #include > extern int errno; > > is correct (POSIX.1) - why this change? If you compile this under Visual Studio 2008 you will get warnings that the errno type being imported is different from the type being exported. The definition I pasted is the one being exported. Perhaps we should use #ifdef WIN32 for this? Gili From bill7007 at gmail.com Tue Apr 7 17:58:54 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Tue, 7 Apr 2009 19:58:54 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: <49D546F8.20807@gatworks.com> <49D693BA.8060909@gatworks.com> Message-ID: I have traced the hang down to a call to tcdrain(fd) in SerialImp.c:drain() running and rebuilt under Netbeans on the target machine with debug messages on. That puts it into the system code, so I'm not sure how to proceed. I guess I could debug into the kernel source but I've not done that. I saw some discussion about an IOCTL that sets/adjusts a timeout on tcdrain() but that may have been for BSD. Maybe there is some new setup requirement or bug introduced with this 2.6.18 kernel or a hardware difference. Below is a message listing with some of the repeated parts removed. Maybe you can see something noteworthy? JNI_OnLoad called. WARNING: RXTX Version mismatch Jar version = RXTX-2.2pre2 native lib Version = RXTX-2.2pre3 entering RXTXCommDriver:getDeviceDirectory entering RXTXPort:testRead fhs_lock: creating lockfile: 29704 fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXPort:testRead RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB2 fhs_lock: creating lockfile: 29704 fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXPort:testRead RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB1 fhs_lock: creating lockfile: 29704 fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXPort:testRead RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB0 fhs_lock: creating lockfile: 29704 fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXPort:testRead fhs_lock: creating lockfile: 29704 ... REPEATS fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXPort:testRead fhs_lock: creating lockfile: 29704 fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXCommDriver:getDeviceDirectory entering RXTXPort:testRead fhs_lock: creating lockfile: 29704 ...REPEATS fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXPort:testRead fhs_lock: creating lockfile: 29704 fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXPort:Initialize RXTX WARNING: This library was compiled to run with OS release 2.6.18 and you are currently running OS release 2.6.18-92.1.6.el5. In some cases this can be a problem. Try recompiling RXTX if you notice strange behavior. If you just compiled RXTX make sure /usr/include/linux is a symbolic link to the include files that came with the kernel source and not an older copy. press enter to continue leaving RXTXPort:Initialize entering RXTXPort:open fhs_lock: creating lockfile: 29704 open: locking worked for /dev/ttyUSB2 open: fd returned is 9 leaving RXTXPort:open entering eventLoop has_line_status_register_acess: Port does not support TIOCSERGETLSR driver_has_tiocgicount: Port does not support TIOCGICOUNT events init_threads: get eis init_threads: set eis init_threads: stop leaving RXTXPort:translate_speed entering RXTXPort:nativeSetSerialPortParams entering translate_date_bits entering translate_stop_bits leaving RXTXPort:translate_stop_bits entering translate_parity leaving translate_parity entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 ...REPEATS entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 leaving RXTXPort:nativeSetSerialPortParams entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 ...REPEATS entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 entering writeArray entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 writeArray() leaving RXTXPort:writeArray entering SerialImp.c:drain() nativeDrain: trying tcdrain RXTXPort:drain() returns: 0 leaving RXTXPort:drain() entering writeArray writeArray() leaving RXTXPort:writeArray entering SerialImp.c:drain() nativeDrain: trying tcdrain entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 Tue Apr 07 18:51:49 EDT 2009:TSerial[22]:Using Port:/dev/ttyUSB2 Tue Apr 07 18:51:49 EDT 2009:TSerial[22].Transmit:TN Tue Apr 07 18:51:49 EDT 2009:TSerial[22].Transmit:RV entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 ...REPEATS FOREVER? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090407/f26e5752/attachment-0003.html From tjarvi at qbang.org Tue Apr 7 18:31:23 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 7 Apr 2009 18:31:23 -0600 (MDT) Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: <49D546F8.20807@gatworks.com> <49D693BA.8060909@gatworks.com> Message-ID: On Tue, 7 Apr 2009, Bill Johnson wrote: > I have traced the hang down to a call to tcdrain(fd) in SerialImp.c:drain() > running and rebuilt under Netbeans on the target machine with debug messages > on. That puts it into the system code, so I'm not sure how to proceed. I > guess I could debug into the kernel source but I've not done that. I saw > some discussion about an IOCTL that sets/adjusts a timeout on tcdrain() but > that may have been for BSD. Maybe there is some new setup requirement or bug > introduced with this 2.6.18 kernel or a hardware difference. > Below is a message listing with some of the repeated parts removed. Maybe > you can see something noteworthy? > > JNI_OnLoad called. > WARNING:? RXTX Version mismatch > ??????? Jar version = RXTX-2.2pre2 > ??????? native lib Version = RXTX-2.2pre3 > entering RXTXCommDriver:getDeviceDirectory > entering RXTXPort:testRead > fhs_lock: creating lockfile:????? 29704 > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXPort:testRead > RXTX Warning:? Removing stale lock file. /var/lock/LCK..ttyUSB2 > fhs_lock: creating lockfile:????? 29704 > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXPort:testRead > RXTX Warning:? Removing stale lock file. /var/lock/LCK..ttyUSB1 > fhs_lock: creating lockfile:????? 29704 > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXPort:testRead > RXTX Warning:? Removing stale lock file. /var/lock/LCK..ttyUSB0 > fhs_lock: creating lockfile:????? 29704 > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXPort:testRead > fhs_lock: creating lockfile:????? 29704 > > ... REPEATS > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXPort:testRead > fhs_lock: creating lockfile:????? 29704 > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXCommDriver:getDeviceDirectory > entering RXTXPort:testRead > fhs_lock: creating lockfile:????? 29704 > > ...REPEATS > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXPort:testRead > fhs_lock: creating lockfile:????? 29704 > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXPort:Initialize > > > > RXTX WARNING:? This library was compiled to run with OS release 2.6.18 and > you are currently running OS release 2.6.18-92.1.6.el5.? In some cases this > can be a problem.? Try recompiling RXTX if you notice strange behavior.? If > you just compiled RXTX make sure /usr/include/linux is a symbolic link to > the include files that came with the kernel source and not an older copy. > > > press enter to continue > > leaving RXTXPort:Initialize > entering RXTXPort:open > fhs_lock: creating lockfile:????? 29704 > > open: locking worked for /dev/ttyUSB2 > open: fd returned is 9 > leaving RXTXPort:open > entering eventLoop > ? > has_line_status_register_acess: Port does not support TIOCSERGETLSR > ?driver_has_tiocgicount:? Port does not support TIOCGICOUNT events > init_threads: get eis > init_threads: set eis > init_threads:? stop > leaving RXTXPort:translate_speed > entering RXTXPort:nativeSetSerialPortParams > entering translate_date_bits > entering translate_stop_bits > leaving RXTXPort:translate_stop_bits > entering translate_parity > leaving translate_parity > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > ...REPEATS > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > leaving RXTXPort:nativeSetSerialPortParams > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > ...REPEATS > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > entering writeArray > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > writeArray() > leaving RXTXPort:writeArray > entering SerialImp.c:drain() > nativeDrain: trying tcdrain > RXTXPort:drain() returns: 0 > leaving RXTXPort:drain() > entering writeArray > writeArray() > leaving RXTXPort:writeArray > entering SerialImp.c:drain() > nativeDrain: trying tcdrain > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > Tue Apr 07 18:51:49 EDT 2009:TSerial[22]:Using Port:/dev/ttyUSB2 > Tue Apr 07 18:51:49 EDT 2009:TSerial[22].Transmit:TN > > Tue Apr 07 18:51:49 EDT 2009:TSerial[22].Transmit:RV > > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > ...REPEATS FOREVER? > > > Hi Bill ugh. The tiocmget... is the eventLoop checking for events. It sits with select() but has a timeout value to keep it spinning at a trivial rate. tcdrain() is the suspect. I don't see anything in the code that looks like a problem. If flow control is not enabled, I don't see a reason for it not to return. Given that this is USB, perhaps a message from the device got lost. Onboard UARTs would have a status register change when output buffer is empty. USB needs to communicate the event as an HID device which may be the source of the error. Dropping back to onboard UARTs eliminates that portion of the mix. What vendor/chipset is the USB dongle? I understand code has been pushed upon the linux serial devices for new for things like acpi. There very well could be a bug introduced. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Apr 7 18:38:22 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 7 Apr 2009 18:38:22 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49DB4212.40807@bbs.darktech.org> References: <49DB4212.40807@bbs.darktech.org> Message-ID: On Tue, 7 Apr 2009, cowwoc wrote: >> just two minor details, first about the errno change, I though >> >> #include >> extern int errno; >> >> is correct (POSIX.1) - why this change? > > If you compile this under Visual Studio 2008 you will get warnings that > the errno type being imported is different from the type being exported. > The definition I pasted is the one being exported. Perhaps we should use > #ifdef WIN32 for this? > Hi Gili, Perhaps a workaround for _MSVC is in order. GNU compilers for windows won't complain. If it's a question of MSVC or POSIX being right, the library favors the standard as a stated goal. I'm not sure what MSVC is using errno for but it should not be using it except with POSIX extensions. Perhaps #undef is enough to get rid of the warning and (maybe) has no ill consequences. Newer windows have POSIX extensions that may show how Microsoft solved the problem. It can probably fester. -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Tue Apr 7 19:54:06 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Tue, 07 Apr 2009 21:54:06 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: References: <49DB4212.40807@bbs.darktech.org> Message-ID: <49DC03BE.5010203@bbs.darktech.org> Trent Jarvi wrote: > I'm not sure what MSVC is using errno for but it should not be using it > except with POSIX extensions. Perhaps #undef is enough to get rid of > the warning and (maybe) has no ill consequences. Newer windows have > POSIX extensions that may show how Microsoft solved the problem. > > It can probably fester. What does "newer windows" refer to in this case? I was compiling using Visual Studio 2008 sp1 under Windows Vista. Both are cutting edge technologies as far as official releases go. I think you're best suited to judge whether this warning is a big deal or not so I think you should see it for yourself. Please try firing up Visual Studio 2008 (express?) against the project I sent you. Gili From Steffen.DETTMER at ingenico.com Wed Apr 8 05:50:42 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 8 Apr 2009 13:50:42 +0200 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49DC03BE.5010203@bbs.darktech.org> References: <49DB4212.40807@bbs.darktech.org> <49DC03BE.5010203@bbs.darktech.org> Message-ID: <20090408115042.GC5090@elberon.bln.de.ingenico.com> * cowwoc wrote on Tue, Apr 07, 2009 at 21:54 -0400: > Trent Jarvi wrote: > > I'm not sure what MSVC is using errno for but it should not be using it > > except with POSIX extensions. Perhaps #undef is enough to get rid of > > the warning and (maybe) has no ill consequences. Newer windows have > > POSIX extensions that may show how Microsoft solved the problem. I think here best is simply to omit this old^Wclassic `extern int errno;' line completely. I think standards just say something like `implementations may support the declaration extern int errno;'. About POSIX extensions I think in general it should be considered that althrough many things are available, even with MS Visual C++, the Microsoft tools lead developers to write non-portable code (and personally I think this is intentional). For example, they call the official ISO-C function `strerror' deprecated (!) and twaddle about some security enhancements (without even beeing specific). Someone could, because of this, lead to use the MS specific, unportable `strerror_s' instead. Even better, at _strerror_s they tell, for `ANSI compatiblity someone should use strerror_s'. Of course a program using [_]strerror_s won't be ANSI-C compliant. Do they mean strerror_r? _strerror_s has the same parameters - but of course in different order - to make porting a pain... SCNR. > What does "newer windows" refer to in this case? I was compiling using > Visual Studio 2008 sp1 under Windows Vista. Both are cutting edge > technologies as far as official releases go. `cutting edge technologies' yeah post-standard, portability-cutting technologies smoothing the way to MS world domination; own post-ANSI-C programming languages help (maybe to increase the share holder value)... SCNR. > I think you're best suited to judge whether this warning is a big deal > or not so I think you should see it for yourself. Please try firing up > Visual Studio 2008 (express?) against the project I sent you. yeah, getting the CL.EXE of 2008 running in a normal command line environment (without its special `C++ Shell') is a bit tricky - but possible. ;) oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From tjarvi at qbang.org Wed Apr 8 14:29:54 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 8 Apr 2009 14:29:54 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49DC03BE.5010203@bbs.darktech.org> References: <49DB4212.40807@bbs.darktech.org> <49DC03BE.5010203@bbs.darktech.org> Message-ID: The support has been around for a long time to. I don't know the details but the support appears to be tied to the OS. http://en.wikipedia.org/wiki/POSIX#POSIX_for_Windows On Tue, 7 Apr 2009, cowwoc wrote: > Trent Jarvi wrote: >> I'm not sure what MSVC is using errno for but it should not be using it >> except with POSIX extensions. Perhaps #undef is enough to get rid of the >> warning and (maybe) has no ill consequences. Newer windows have POSIX >> extensions that may show how Microsoft solved the problem. >> >> It can probably fester. > > What does "newer windows" refer to in this case? I was compiling > using Visual Studio 2008 sp1 under Windows Vista. Both are cutting edge > technologies as far as official releases go. > > I think you're best suited to judge whether this warning is a big > deal or not so I think you should see it for yourself. Please try firing up > Visual Studio 2008 (express?) against the project I sent you. > > Gili > From bill7007 at gmail.com Wed Apr 8 15:59:08 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Wed, 8 Apr 2009 17:59:08 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: <49D546F8.20807@gatworks.com> <49D693BA.8060909@gatworks.com> Message-ID: Hi Trent, I think I have hit on a work around but don't know why it works. The USB serial adapter is a "CableMAX" based on Prolific's PL2303. Backing out to the big picture, the application is old and has been very reliable until put on a new cpu and kernel. It only hangs sometimes say 25% and always at the same place, at tcdrain() on the flush() after the second write after startup. If it made it past this stage, all transmit and receive seemed reliable so it was like a startup timing issue. Since learning to debug kernel code is beyond my immediate priority, I took a shot at moving code around, adding delays, and such. I have found it good practice to do a flush after every write on streams like: outputStream.write(data.getBytes()); outputStream.flush(); If I remove the flush() after each write, the problem appears to go away! I don't think the flush is needed for a SerialOutputStream for this application anyway. Thanks for all the help, +BillJ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090408/35d96a9d/attachment-0001.html From bill7007 at gmail.com Thu Apr 9 09:20:11 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Thu, 9 Apr 2009 11:20:11 -0400 Subject: [Rxtx] Baud rate fixes in 2.2pre2 breaks 38400 on some Linux devices Message-ID: Hello, An application that worked at 38400 on a USB serial adapter (PL2303) using 2.1-7-r2 on Linux EL4 (and EL5) now fails using 2.2pre2. serialPort.setSerialPortParams(38400,SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); throws an unsupportedCommOperationException This problem matched a description of Bug 113and I posted a proposed patch there, but I don't understand the whole custom baud rate patch so it may need some thought. An older patch, [Rxtx] [Patch]: Baud Rate fixes try 1, testing encouraged., fixed some custom baud rates but apparently broke 38400 on some Linux device. Other baud rates seem to work OK. And, 38400 tested OK on local non-USB ports. My proposed patch probably breaks the custom baud rate patch since it was keyed on 38400 as a special case for Linux and my fix was to back out part of that patch, specifically: #if defined(TIOCGSERIAL) if ( cspeed == B38400 ) cspeed = 38400; #endif /* TIOCGSERIAL */ +BillJ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090409/5636af64/attachment.html From cowwoc at bbs.darktech.org Wed Apr 1 22:05:13 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Thu, 02 Apr 2009 00:05:13 -0400 Subject: [Rxtx] Windows 64-bit support? Message-ID: <49D43979.4050702@bbs.darktech.org> Hi, I'd like to run RXTX under the Windows 64-bit JVM. Are there plans to release an official 64-bit version anytime soon? Gili From bill7007 at gmail.com Thu Apr 2 16:01:17 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Thu, 2 Apr 2009 18:01:17 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel Message-ID: Hi, I have an rxtx serial application that used to work reliably until I had to move it to newer hardware and kernel. Now, the application sometimes hangs near first port use. When it does hang, it can be released by starting a second copy of the application which is locked out of the ports but does release the first process. Upgraded from rxtx-2.1-7-r2 to rxtx-2.2pre2 but still hangs. Tried to rebuild on the target machine and ran into the 'UTS_RELEASE' undeclared problem so holding on that approach. Recompiled OK on a 2.6.9-42.0.3.ELsmp system. Debug messages were turned on using: "./configure --enable-DEBUG" and modified RXTXPort.java with: "debug = true;" "z = new Zystem(Zystem.PRINT_MODE);" Below is capture of the application with debugging enabled. It show the application hang point, and the second application's printout at the release point. (pre3 is the locally modified version of pre2) Any suggestions on how to pin this down further? Thanks, +BillJ $ java -version java version "1.5.0_06" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05) Java HotSpot(TM) Client VM (build 1.5.0_06-b05, mixed mode, sharing) $ uname -a Linux qms4 2.6.18-92.1.6.el5 #1 SMP Wed Jun 25 13:49:24 EDT 2008 i686 i686 i386 GNU/Linux ***CAPTURE: [qms at qms4 ~]$ ./qms/ScriptFiles/startup.sh Thu Apr 02 13:35:45 EDT 2009:Setting Log File to:/home/qms/qms/QMS.log Thu Apr 02 13:35:45 EDT 2009:TSettings.HandleIni:ReUsing Ini file:/home/qms/qms/qms.properties WARNING: RXTX Version mismatch Jar version = RXTX-2.2pre2 native lib Version = RXTX-2.2pre3 fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB2 fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB1 fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB0 fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile RXTXPort {} RXTX WARNING: This library was compiled to run with OS release 2.4.20 and you are currently running OS release 2.6.18-92.1.6.el5. In some cases this can be a problem. Try recompiling RXTX if you notice strange behavior. If you just compiled RXTX make sure /usr/include/linux is a symbolic link to the include files that came with the kernel source and not an older copy. press enter to continue RXTXPort:RXTXPort(/dev/ttyUSB2) called fhs_lock: creating lockfile: 10127 open: locking worked for /dev/ttyUSB2 open: fd returned is 8 RXTXPort:MontitorThread:MonitorThread() RXTXPort:MontitorThread:run() has_line_status_register_acess: Port does not support TIOCSERGETLSR init_threads: get eis init_threads: set eis init_threads: stop RXTXPort:RXTXPort(/dev/ttyUSB2) returns with fd = 8 RXTXPort:setSerialPortParams(38400 8 1 0) called RXTXPort:setSerialPortParams(38400 8 1 0) returning RXTXPort:getInputStream() called and returning Thu Apr 02 13:36:02 EDT 2009:TSerial[22]:Using Port:/dev/ttyUSB2 RXTXPort:getOutputStream() called and returning Thu Apr 02 13:36:02 EDT 2009:TSerial[22].Transmit:TN Entering RXTXPort:SerialOutputStream:write(4) writeArray() Leaving RXTXPort:SerialOutputStream:write(4) RXTXPort:SerialOutputStream:flush() enter RXTXPort:SerialOutputStream:flush() leave Thu Apr 02 13:36:02 EDT 2009:TSerial[22].Transmit:RV Entering RXTXPort:SerialOutputStream:write(4) writeArray() Leaving RXTXPort:SerialOutputStream:write(4) RXTXPort:SerialOutputStream:flush() enter RXTXPort:SerialInputStream:read(8192 0 8192) called ***FIRST PROCESS HANGS HERE ***THEN PROCEEDS AFTER SECOND PROCESS STARTS RXTXPort:SerialOutputStream:flush() leave Thu Apr 02 13:41:29 EDT 2009:TSerial[22].Transmit:IH9 Entering RXTXPort:SerialOutputStream:write(5) writeArray() Leaving RXTXPort:SerialOutputStream:write(5) RXTXPort:SerialOutputStream:flush() enter RXTXPort:SerialOutputStream:flush() leave Thu Apr 02 13:41:29 EDT 2009:TSerial[22].Transmit:IL11 ***END CAPTURE ***CAPTURE SECOND PROCESS FAILS OPEN [qms at qms4 ~]$ ./qms/ScriptFiles/startup.sh Thu Apr 02 13:41:27 EDT 2009:Setting Log File to:/home/qms/qms/QMS.log Thu Apr 02 13:41:27 EDT 2009:TSettings.HandleIni:ReUsing Ini file:/home/qms/qms/qms.properties WARNING: RXTX Version mismatch Jar version = RXTX-2.2pre2 native lib Version = RXTX-2.2pre3 fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB2: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB1: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB0: File exists fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB2: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB1: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB0: File exists fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile Thu Apr 02 13:41:30 EDT 2009:TIOBoard: java.io.IOException: java.io.IOException: TSerial[22]: Open Failed ***END CAPTURE -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090402/c66f8d70/attachment-0009.html From netbeans at gatworks.com Thu Apr 2 17:15:04 2009 From: netbeans at gatworks.com (U. George) Date: Thu, 02 Apr 2009 19:15:04 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: Message-ID: <49D546F8.20807@gatworks.com> > "z = new Zystem(Zystem.PRINT_MODE);" > Below is capture of the application with debugging enabled. It show > the application hang point, and the second application's printout at the > release point. (pre3 is the locally modified version of pre2) > Any suggestions on how to pin this down further? > Thanks, > +BillJ When perceived runability is hung, try a ^\ ( control \) on console. This gets the JVM to dump the stacks of all the java threads. If you know the thread that is stuck, then u can see what java statement its stuck at. From tjarvi at qbang.org Thu Apr 2 19:25:17 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 2 Apr 2009 19:25:17 -0600 (MDT) Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: <49D546F8.20807@gatworks.com> References: <49D546F8.20807@gatworks.com> Message-ID: On Thu, 2 Apr 2009, U. George wrote: >> "z = new Zystem(Zystem.PRINT_MODE);" >> Below is capture of the application with debugging enabled. It show >> the application hang point, and the second application's printout at the >> release point. (pre3 is the locally modified version of pre2) >> Any suggestions on how to pin this down further? >> Thanks, >> +BillJ > > When perceived runability is hung, try a ^\ ( control \) on console. > This gets the JVM to dump the stacks of all the java threads. > If you know the thread that is stuck, then u can see what java statement > its stuck at. I've also noticed some linux systems hanging with open/read/write and saw kacpid storms. I need to look at it more but did observe kacpid consuming a core and not returning to a normal state for a significant period of time. It was easy to observe from top sorted by CPU usage. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Apr 2 19:26:18 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 2 Apr 2009 19:26:18 -0600 (MDT) Subject: [Rxtx] Windows 64-bit support? In-Reply-To: <49D43979.4050702@bbs.darktech.org> References: <49D43979.4050702@bbs.darktech.org> Message-ID: On Thu, 2 Apr 2009, cowwoc wrote: > Hi, > > I'd like to run RXTX under the Windows 64-bit JVM. Are there plans > to release an official 64-bit version anytime soon? > It is in the prerelease and will be in the final release. I'm pushing it through as fast as I can in my free time. -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Thu Apr 2 22:57:34 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Fri, 03 Apr 2009 00:57:34 -0400 Subject: [Rxtx] Missing documentation In-Reply-To: References: <49D43979.4050702@bbs.darktech.org> Message-ID: <49D5973E.4050400@bbs.darktech.org> Hi, I noticed that RXTX 2.1 drops javax.comm support in favor of gnu.io. I have one major problem with this: the gui.io.* documentation is very poor. Many classes and methods have no Javadoc at all which makes them difficult to use. Please fix this for the final release. Thank you, Gili From alex.sas at freemail.hu Fri Apr 3 01:36:54 2009 From: alex.sas at freemail.hu (Sas Alex) Date: Fri, 3 Apr 2009 09:36:54 +0200 (CEST) Subject: [Rxtx] Serial port false reads Message-ID: Hi all, On Windows XP, using rxtx-2.1-7-r2 I have a program communicating on a serial line like the following (excerpt): { os.write(command); os.flush(); // Thread.sleep(period); // read response while(is.available() > 0) { is.read() } } If there is a sleep between the os.flush and the reading cycle the correct answer is received. Otherwise (sometimes) there are extra, erronous characters at the beginning of the answer, but the correct answer (according to the protocol) also arrives, afterwards. Is this a normal behaviour, one should wait before the read? If yes, is there a way to determine the minimum amount of time to wait for? Serial port params are: 9600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE. Thank you in advance, Alex ________________________________________________________ El?foglal?si akci? meghosszabb?tva! Korfui ?d?l?s m?r 56.910 Ft-t?l. http://www.budavartours.hu/gorogorszag/?utm_campaign=origo&utm_source=freemail_kimeno_090403&utm_medium=ct&utm_content=korfu_elofoglalasi_akcio#reg_Korfu -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090403/8f3650ea/attachment-0009.html From bill7007 at gmail.com Fri Apr 3 16:15:30 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Fri, 3 Apr 2009 18:15:30 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: <49D546F8.20807@gatworks.com> Message-ID: > When perceived runability is hung, try a ^\ ( control \) on console. >> This gets the JVM to dump the stacks of all the java threads. > > Good idea... A thread dump is below, it looks like only some system threads are in wait state which is probably normal. The "main" thread is stopped writing the first data out the serial port which should complete but its has stopped at: at gnu.io.RXTXPort.nativeDrain(Native Method) It show its state as runnable though. There is another thread, "SerialReader_22", that is waiting to read any data on the same port. I'll bring the app up under Netbeans debugger next. >> > I've also noticed some linux systems hanging with open/read/write and saw > kacpid storms. No CPU use going when it hangs, acts like a deadlock. THREAD DUMP AT HANG: Entering RXTXPort:SerialOutputStream:write(4) writeArray() Leaving RXTXPort:SerialOutputStream:write(4) RXTXPort:SerialOutputStream:flush() enter RXTXPort:SerialInputStream:read(8192 0 8192) called Full thread dump Java HotSpot(TM) Client VM (1.5.0_06-b05 mixed mode, sharing): "SerialReader_22" daemon prio=1 tid=0x087abf38 nid=0x3c8b runnable [0xb1a43000..0xb1a43f30] at gnu.io.RXTXPort.readArray(Native Method) at gnu.io.RXTXPort$SerialInputStream.read(RXTXPort.java:1454) - locked <0x88ca55b8> (a gnu.io.RXTXPort$SerialInputStream) at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:411) at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) - locked <0x88cab378> (a java.io.InputStreamReader) at java.io.InputStreamReader.read(InputStreamReader.java:167) at java.io.BufferedReader.fill(BufferedReader.java:136) at java.io.BufferedReader.readLine(BufferedReader.java:299) - locked <0x88cab378> (a java.io.InputStreamReader) at java.io.BufferedReader.readLine(BufferedReader.java:362) at qms.TSerialPort$SerialRead.run(TSerialPort.java:268) at java.lang.Thread.run(Thread.java:595) "Thread-1" prio=1 tid=0x08a43360 nid=0x3c8a runnable [0xb1ac4000..0xb1ac4db0] at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1641) "AWT-XAWT" daemon prio=1 tid=0x08acc848 nid=0x3c87 runnable [0xb1b45000..0xb1b45e30] at sun.awt.X11.XToolkit.waitForEvents(Native Method) at sun.awt.X11.XToolkit.run(XToolkit.java:463) at sun.awt.X11.XToolkit.run(XToolkit.java:438) at java.lang.Thread.run(Thread.java:595) "Java2D Disposer" daemon prio=1 tid=0x08ab9d30 nid=0x3c86 in Object.wait() [0xb1bc6000..0xb1bc70b0] at java.lang.Object.wait(Native Method) - waiting on <0x8917b110> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:116) - locked <0x8917b110> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:132) at sun.java2d.Disposer.run(Disposer.java:107) at java.lang.Thread.run(Thread.java:595) "Low Memory Detector" daemon prio=1 tid=0x087bea68 nid=0x3c84 runnable [0x00000000..0x00000000] "CompilerThread0" daemon prio=1 tid=0x087bd4c0 nid=0x3c83 waiting on condition [0x00000000..0xb23a7a18] "Signal Dispatcher" daemon prio=1 tid=0x087bc520 nid=0x3c82 runnable [0x00000000..0x00000000] "Finalizer" daemon prio=1 tid=0x087b5710 nid=0x3c81 in Object.wait() [0xb26a9000..0xb26a9f30] at java.lang.Object.wait(Native Method) - waiting on <0x8914a770> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:116) - locked <0x8914a770> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:132) at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159) "Reference Handler" daemon prio=1 tid=0x087b49c8 nid=0x3c80 in Object.wait() [0xb272a000..0xb272adb0] at java.lang.Object.wait(Native Method) - waiting on <0x8914a7f0> (a java.lang.ref.Reference$Lock) at java.lang.Object.wait(Object.java:474) at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116) - locked <0x8914a7f0> (a java.lang.ref.Reference$Lock) "main" prio=1 tid=0x08777b88 nid=0x3c7e runnable [0xbffa7000..0xbffa74f8] at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1248) at qms.TSerialPort.Transmit(TSerialPort.java:192) - locked <0x88c99a68> (a qms.TSerialPort) at qms.TIOBoard.GetIOBoardVersion(TIOBoard.java:168) at qms.TIOBoard.(TIOBoard.java:73) at qms.TQMS.(TQMS.java:47) at qms.MainForm.(MainForm.java:2076) at qms.MainForm.main(MainForm.java:2099) "VM Thread" prio=1 tid=0x087b1e20 nid=0x3c7f runnable "VM Periodic Task Thread" prio=1 tid=0x087bff50 nid=0x3c85 waiting on condition -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090403/20b7bca4/attachment-0008.html From Martin.Oberhuber at windriver.com Fri Apr 3 16:23:43 2009 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Sat, 4 Apr 2009 00:23:43 +0200 Subject: [Rxtx] Missing documentation In-Reply-To: <49D5973E.4050400@bbs.darktech.org> References: <49D43979.4050702@bbs.darktech.org> <49D5973E.4050400@bbs.darktech.org> Message-ID: <460801A4097E3D4CA04CC64EE648584809C8BD6F@ism-mail03.corp.ad.wrs.com> Hello Gili, The classes in the gnu.io namespace are designed to work exactly as their counterparts in the javax.comm namespace. Therefore, if you just take the javax.comm Javadocs that's what you want. Unfortunately I don't think we can just copy & paste the javax.comm Javadocs into RXTX due to license restrictions. I guess that's the main reason why RXTX is not (yet) Javadoc'd as extensively as it should be. Actually, writing Javadocs from scratch WITHOUT referencing the wording of the Sun Javadocs is not that easy. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of cowwoc > Sent: Freitag, 03. April 2009 06:58 > To: rxtx at qbang.org > Subject: [Rxtx] Missing documentation > > Hi, > > I noticed that RXTX 2.1 drops javax.comm support in favor > of gnu.io. > I have one major problem with this: the gui.io.* > documentation is very > poor. Many classes and methods have no Javadoc at all which > makes them > difficult to use. Please fix this for the final release. > > Thank you, > Gili > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Fri Apr 3 16:54:50 2009 From: netbeans at gatworks.com (U. George) Date: Fri, 03 Apr 2009 18:54:50 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: <49D546F8.20807@gatworks.com> Message-ID: <49D693BA.8060909@gatworks.com> I would have tried 2 or 3 "^\" . If things are stuck, then all will be at same 'java' instruction. If thread is moving, then one of the snapshots would be different. I *think* flushing/draining wont return until the kernel buffers to device have been accepted by device. Stuck/paused device? Bill Johnson wrote: > > > > > When perceived runability is hung, try a ^\ ( control \) on console. > This gets the JVM to dump the stacks of all the java threads. > > > Good idea... A thread dump is below, it looks like only some system > threads are in wait state which is prob From cowwoc at bbs.darktech.org Fri Apr 3 17:45:09 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Fri, 03 Apr 2009 19:45:09 -0400 Subject: [Rxtx] Missing documentation In-Reply-To: <460801A4097E3D4CA04CC64EE648584809C8BD6F@ism-mail03.corp.ad.wrs.com> References: <49D43979.4050702@bbs.darktech.org> <49D5973E.4050400@bbs.darktech.org> <460801A4097E3D4CA04CC64EE648584809C8BD6F@ism-mail03.corp.ad.wrs.com> Message-ID: <49D69F85.3030804@bbs.darktech.org> You could always send Sun a formal email and ask for permission to copy their Javadoc. I doubt they would give you problems. Gili Oberhuber, Martin wrote: > Hello Gili, > > The classes in the gnu.io namespace are designed to work exactly > as their counterparts in the javax.comm namespace. Therefore, > if you just take the javax.comm Javadocs that's what you want. > > Unfortunately I don't think we can just copy & paste the > javax.comm Javadocs into RXTX due to license restrictions. > > I guess that's the main reason why RXTX is not (yet) Javadoc'd > as extensively as it should be. Actually, writing Javadocs > from scratch WITHOUT referencing the wording of the Sun > Javadocs is not that easy. > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] >> On Behalf Of cowwoc >> Sent: Freitag, 03. April 2009 06:58 >> To: rxtx at qbang.org >> Subject: [Rxtx] Missing documentation >> >> Hi, >> >> I noticed that RXTX 2.1 drops javax.comm support in favor >> of gnu.io. >> I have one major problem with this: the gui.io.* >> documentation is very >> poor. Many classes and methods have no Javadoc at all which >> makes them >> difficult to use. Please fix this for the final release. >> >> Thank you, >> Gili >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> From cowwoc at bbs.darktech.org Sat Apr 4 15:13:38 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sat, 04 Apr 2009 17:13:38 -0400 Subject: [Rxtx] Java5 support Message-ID: <49D7CD82.1040904@bbs.darktech.org> Now that you dropped javax.comm support, how about improving the API by replacing Enumation by Iterator, int by enum, and using Generics? It would improve the usability of the API. Gili From cowwoc at bbs.darktech.org Sat Apr 4 16:12:13 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sat, 04 Apr 2009 18:12:13 -0400 Subject: [Rxtx] RXTX Version mismatch in 2.2pre2 Message-ID: <49D7DB3D.5040008@bbs.darktech.org> When using RXTX-2.2pre2 I always get the following message: WARNING: RXTX Version mismatch Jar version = RXTX-2.2pre1 native lib Version = RXTX-2.2pre2 I have double checked that I am using the correct Jar file. Is this a known bug in pre2? Gili From tjarvi at qbang.org Sat Apr 4 16:48:53 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Apr 2009 16:48:53 -0600 (MDT) Subject: [Rxtx] RXTX Version mismatch in 2.2pre2 In-Reply-To: <49D7DB3D.5040008@bbs.darktech.org> References: <49D7DB3D.5040008@bbs.darktech.org> Message-ID: > When using RXTX-2.2pre2 I always get the following message: > > WARNING: RXTX Version mismatch > Jar version = RXTX-2.2pre1 > native lib Version = RXTX-2.2pre2 > Yep. You should still be able to test it. -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Sat Apr 4 16:50:43 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sat, 04 Apr 2009 18:50:43 -0400 Subject: [Rxtx] RXTX Version mismatch in 2.2pre2 In-Reply-To: References: <49D7DB3D.5040008@bbs.darktech.org> Message-ID: <49D7E443.9070404@bbs.darktech.org> In other words this is a known bug that will be fixed in the final version? Gili Trent Jarvi wrote: > > >> When using RXTX-2.2pre2 I always get the following message: >> >> WARNING: RXTX Version mismatch >> Jar version = RXTX-2.2pre1 >> native lib Version = RXTX-2.2pre2 >> > > Yep. > > You should still be able to test it. > > -- > Trent Jarvi > tjarvi at qbang.org From cowwoc at bbs.darktech.org Sat Apr 4 16:57:34 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sat, 04 Apr 2009 18:57:34 -0400 Subject: [Rxtx] IOException: Underlying input stream returned zero bytes Message-ID: <49D7E5DE.2050405@bbs.darktech.org> Hi, There seems to be a bug in RXTX 2.2pre2's handling of InputStream timeouts. If you open a serial port without ever invoking enableReceiveTimeout() then invoking InputStream.read() will always return 0 bytes right away. If you wrap the InputStream and invoke BufferedReader.readline() you will get the following exception: java.io.IOException: Underlying input stream returned zero bytes at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:268) [na:1.6.0_14-ea] at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:306) [na:1.6.0_14-ea] at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:158) [na:1.6.0_14-ea] at java.io.InputStreamReader.read(InputStreamReader.java:167) [na:1.6.0_14-ea] at java.io.BufferedReader.fill(BufferedReader.java:136) [na:1.6.0_14-ea] at java.io.BufferedReader.readLine(BufferedReader.java:299) [na:1.6.0_14-ea] at java.io.BufferedReader.readLine(BufferedReader.java:362) [na:1.6.0_14-ea] [snip] If you enable a timeout, the exception will only occur after the timeout expires. In short, it looks like RXTX is using a default timeout of zero (I am expecting it to block forever). It looks like other people have run into this as well: http://forums.sun.com/thread.jspa?threadID=5165346&start=10&tstart=0 Please confirm whether this is a known bug. Thank you, Gili From tjarvi at qbang.org Sat Apr 4 17:27:19 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Apr 2009 17:27:19 -0600 (MDT) Subject: [Rxtx] IOException: Underlying input stream returned zero bytes In-Reply-To: <49D7E5DE.2050405@bbs.darktech.org> References: <49D7E5DE.2050405@bbs.darktech.org> Message-ID: On Sat, 4 Apr 2009, cowwoc wrote: > Hi, > > There seems to be a bug in RXTX 2.2pre2's handling of InputStream > timeouts. If you open a serial port without ever invoking > enableReceiveTimeout() then invoking InputStream.read() will always > return 0 bytes right away. If you wrap the InputStream and invoke > BufferedReader.readline() you will get the following exception: > > java.io.IOException: Underlying input stream returned zero bytes > at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:268) > [na:1.6.0_14-ea] > at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:306) > [na:1.6.0_14-ea] > at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:158) > [na:1.6.0_14-ea] > at java.io.InputStreamReader.read(InputStreamReader.java:167) > [na:1.6.0_14-ea] > at java.io.BufferedReader.fill(BufferedReader.java:136) > [na:1.6.0_14-ea] > at java.io.BufferedReader.readLine(BufferedReader.java:299) > [na:1.6.0_14-ea] > at java.io.BufferedReader.readLine(BufferedReader.java:362) > [na:1.6.0_14-ea] > [snip] > > If you enable a timeout, the exception will only occur after the > timeout expires. In short, it looks like RXTX is using a default timeout > of zero (I am expecting it to block forever). It looks like other people > have run into this as well: > http://forums.sun.com/thread.jspa?threadID=5165346&start=10&tstart=0 > > Please confirm whether this is a known bug. > Hi Gili I've known about it but was not sure if it was a bug or not. It looks like we can treat it as a bug if nio is throwing an exception. Timeout and Thresholds are well documented in javax.comm but I didn't recall seeing defaults. For that reason, I've encouraged people to set the threshold and timeout to what they expect. Another note about InputStream.read(void): I noticed that I don't use that function at all while looking at code coverage results. Keep your eye out for additional issues. -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Sat Apr 4 19:03:29 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sat, 04 Apr 2009 21:03:29 -0400 Subject: [Rxtx] IOException: Underlying input stream returned zero bytes In-Reply-To: References: <49D7E5DE.2050405@bbs.darktech.org> Message-ID: <49D80361.7020801@bbs.darktech.org> Trent Jarvi wrote: > For that reason, I've encouraged people to set the threshold and timeout > to what they expect. It doesn't help. There doesn't seem to be a way to disable the timeout, even if you invoke disableReceiveTimeout() explicitly. Let me know when you put in a fix and I will test it. Thanks, Gili From cowwoc at bbs.darktech.org Sat Apr 4 23:27:25 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 01:27:25 -0400 Subject: [Rxtx] Crash in termios.c:892 Message-ID: <49D8413D.7040105@bbs.darktech.org> I can reproduce a crash in RXTX 2.2 pre2 100% of the time using my application code, but I can't seem to bring it down to a minimal testcase. Here is what I see: - thread begins running - open com1 - close com1 - open com5 - leave com5 open - thread shuts down - repeat the same process in a new thread - crash occurs when trying to open com1. Crash disappears if I close() com5 in the previous thread. The output window contains the following: # # A fatal error has been detected by the Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x05475cf6, pid=6064, tid=5436 # # JRE version: 6.0_14-b04 # Java VM: Java HotSpot(TM) Client VM (14.0-b13 mixed mode, sharing windows-x86 ) # Problematic frame: # C [rxtxSerial.dll+0x5cf6] # # An error report file with more information is saved as: # C:\Users\Gili\Documents\foobar\source\hs_err_pid6064.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp Error 0x5 at ..\src\termios.c(892): Access is denied. # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # Please let me know if the crash dump is enough to track down this bug. Thank you, Gili -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: hs_err_pid6064.log Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20090405/7133a1ce/attachment-0005.pl From cowwoc at bbs.darktech.org Sun Apr 5 00:24:19 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 02:24:19 -0400 Subject: [Rxtx] SerialPort.getName() is wrong Message-ID: <49D84E93.7050606@bbs.darktech.org> Sorry for all these emails but I keep on running into more issues. Here is what I noticed: - CommPortIdentifier.getPortIdentifier("COM5") returns a CommPortIdentifier where getName() == "COM5" - If, however, you invoke CommPortIdentifier.open() you get back a SerialPort where SerialPort.getName() is "//./COM5" I am expecting the name to remain consistent. "//./COM5" looks like an implementation detail and (as far as I can tell) it can't be used as an argument for any API method so it is somewhat useless. If getName() were to return "COM5" I could at least use it to get back the original CommPortIdentifier or compare against "known names" such as "COMx" or "LPTx". What do you think? Gili From tjarvi at qbang.org Sun Apr 5 10:18:42 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Apr 2009 10:18:42 -0600 (MDT) Subject: [Rxtx] SerialPort.getName() is wrong In-Reply-To: <49D84E93.7050606@bbs.darktech.org> References: <49D84E93.7050606@bbs.darktech.org> Message-ID: On Sun, 5 Apr 2009, cowwoc wrote: > > Sorry for all these emails but I keep on running into more issues. > Here is what I noticed: > > - CommPortIdentifier.getPortIdentifier("COM5") returns a > CommPortIdentifier where getName() == "COM5" > - If, however, you invoke CommPortIdentifier.open() you get back a > SerialPort where SerialPort.getName() is "//./COM5" > > I am expecting the name to remain consistent. "//./COM5" looks like > an implementation detail and (as far as I can tell) it can't be used as > an argument for any API method so it is somewhat useless. If getName() > were to return "COM5" I could at least use it to get back the original > CommPortIdentifier or compare against "known names" such as "COMx" or > "LPTx". What do you think? > Sure. If it itches enough you should be able to fix this in RXTXCommDriver.java. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Apr 5 10:27:58 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Apr 2009 10:27:58 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D8413D.7040105@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> Message-ID: On Sun, 5 Apr 2009, cowwoc wrote: > > I can reproduce a crash in RXTX 2.2 pre2 100% of the time using my > application code, but I can't seem to bring it down to a minimal testcase. > Here is what I see: > > - thread begins running > - open com1 > - close com1 > - open com5 > - leave com5 open > - thread shuts down > - repeat the same process in a new thread > - crash occurs when trying to open com1. Crash disappears if I close() com5 > in the previous thread. > > The output window contains the following: > > # > # A fatal error has been detected by the Java Runtime Environment: > # > # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x05475cf6, pid=6064, > tid=5436 > # > # JRE version: 6.0_14-b04 > # Java VM: Java HotSpot(TM) Client VM (14.0-b13 mixed mode, sharing > windows-x86 ) > # Problematic frame: > # C [rxtxSerial.dll+0x5cf6] > # > # An error report file with more information is saved as: > # C:\Users\Gili\Documents\foobar\source\hs_err_pid6064.log > # > # If you would like to submit a bug report, please visit: > # http://java.sun.com/webapps/bugreport/crash.jsp > Error 0x5 at ..\src\termios.c(892): Access is denied. > > > # The crash happened outside the Java Virtual Machine in native code. > # See problematic frame for where to report the bug. > # > > Please let me know if the crash dump is enough to track down this bug. > Hi Gili, You are responsible for cleaning up the serial ports when using threads. That said, if the thread did shut down, finalize should have been called if you are not passing the object around. See RXTXPort.java. protected void finalize() { if (debug) z.reportln( "RXTXPort:finalize()"); if( fd > 0 ) { if (debug) z.reportln( "RXTXPort:calling close()"); close(); } z.finalize(); } The exception is interesting. This is on Vista? Usually it just gives an open error when another process has the port. -- Trent Jarvi tjarvi at mathworks.com From cowwoc at bbs.darktech.org Sun Apr 5 10:35:55 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 12:35:55 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: References: <49D8413D.7040105@bbs.darktech.org> Message-ID: <49D8DDEB.5010908@bbs.darktech.org> Trent Jarvi wrote: > You are responsible for cleaning up the serial ports when using threads. > That said, if the thread did shut down, finalize should have been called > if you are not passing the object around. See RXTXPort.java. > > protected void finalize() > { > if (debug) > z.reportln( "RXTXPort:finalize()"); > if( fd > 0 ) > { > if (debug) > z.reportln( "RXTXPort:calling close()"); > close(); > } > z.finalize(); > } Two points: 1) One should never rely on finalizers because they may never run. 2) RXTX shouldn't cause the entire JVM to crash if I misuse the API. The native code should recover more gracefully. > The exception is interesting. This is on Vista? Usually it just gives > an open error when another process has the port. Yes, this is on Vista 64-bit. I'd really like to see this bug fixed. Is this code compilable under Visual Studio? If so, I can debug the problem on my end and send you a patch. Thanks, Gili From cowwoc at bbs.darktech.org Sun Apr 5 10:36:20 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 12:36:20 -0400 Subject: [Rxtx] SerialPort.getName() is wrong In-Reply-To: References: <49D84E93.7050606@bbs.darktech.org> Message-ID: <49D8DE04.6030306@bbs.darktech.org> Trent Jarvi wrote: >> I am expecting the name to remain consistent. "//./COM5" looks like >> an implementation detail and (as far as I can tell) it can't be used as >> an argument for any API method so it is somewhat useless. If getName() >> were to return "COM5" I could at least use it to get back the original >> CommPortIdentifier or compare against "known names" such as "COMx" or >> "LPTx". What do you think? >> > > Sure. > > If it itches enough you should be able to fix this in RXTXCommDriver.java. I'm not sure I understand. Are you saying that if I submit a patch you will commit it? Gili From tjarvi at qbang.org Sun Apr 5 10:46:23 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Apr 2009 10:46:23 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D8DDEB.5010908@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> Message-ID: On Sun, 5 Apr 2009, cowwoc wrote: > Trent Jarvi wrote: >> You are responsible for cleaning up the serial ports when using threads. >> That said, if the thread did shut down, finalize should have been called if >> you are not passing the object around. See RXTXPort.java. >> >> protected void finalize() >> { >> if (debug) >> z.reportln( "RXTXPort:finalize()"); >> if( fd > 0 ) >> { >> if (debug) >> z.reportln( "RXTXPort:calling close()"); >> close(); >> } >> z.finalize(); >> } > > Two points: > > 1) One should never rely on finalizers because they may never run. > 2) RXTX shouldn't cause the entire JVM to crash if I misuse the API. The > native code should recover more gracefully. > >> The exception is interesting. This is on Vista? Usually it just gives an >> open error when another process has the port. > > Yes, this is on Vista 64-bit. I'd really like to see this bug fixed. > Is this code compilable under Visual Studio? If so, I can debug the problem > on my end and send you a patch. > It will compile with the msvc cl.exe and nmake. See Makefile.msvc in the top level directory. You will need to adjust the JAVA_HOME variable. Also use the MSVC command prompt for x86_64 so cl and nmake are on your path. All the best, -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Apr 5 10:49:10 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Apr 2009 10:49:10 -0600 (MDT) Subject: [Rxtx] SerialPort.getName() is wrong In-Reply-To: <49D8DE04.6030306@bbs.darktech.org> References: <49D84E93.7050606@bbs.darktech.org> <49D8DE04.6030306@bbs.darktech.org> Message-ID: On Sun, 5 Apr 2009, cowwoc wrote: > Trent Jarvi wrote: >>> I am expecting the name to remain consistent. "//./COM5" looks like >>> an implementation detail and (as far as I can tell) it can't be used as >>> an argument for any API method so it is somewhat useless. If getName() >>> were to return "COM5" I could at least use it to get back the original >>> CommPortIdentifier or compare against "known names" such as "COMx" or >>> "LPTx". What do you think? >>> >> >> Sure. >> >> If it itches enough you should be able to fix this in RXTXCommDriver.java. > > I'm not sure I understand. Are you saying that if I submit a patch > you will commit it? > Hi Gili, Post a patch here and if nobody complains, we will commit it and give you credit. Yep. Other issues like changing the API to use java5 that may break existing apps are likely to run into objections but bug fixes usually get fixed just as you mention. -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Sun Apr 5 10:55:07 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 12:55:07 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> Message-ID: <49D8E26B.2040705@bbs.darktech.org> Trent Jarvi wrote: > It will compile with the msvc cl.exe and nmake. See Makefile.msvc in > the top level directory. You will need to adjust the JAVA_HOME > variable. Also use the MSVC command prompt for x86_64 so cl and nmake > are on your path. This is very odd. The CVS version of the code does not contain this file. Do you keep the latest code somewhere else? Gili From cowwoc at bbs.darktech.org Sun Apr 5 11:01:58 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 13:01:58 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D8E26B.2040705@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> Message-ID: <49D8E406.10708@bbs.darktech.org> cowwoc wrote: > Trent Jarvi wrote: >> It will compile with the msvc cl.exe and nmake. See Makefile.msvc in >> the top level directory. You will need to adjust the JAVA_HOME >> variable. Also use the MSVC command prompt for x86_64 so cl and nmake >> are on your path. > > This is very odd. The CVS version of the code does not contain this > file. Do you keep the latest code somewhere else? Okay I figured it out. CVS head is out of date, the "commapi-0-0-1" revision contains the correct files. Gili From tjarvi at qbang.org Sun Apr 5 11:05:43 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Apr 2009 11:05:43 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D8E26B.2040705@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> Message-ID: CVS HEAD is currently the rxtx 2.0 code. A branch was created long ago for 'experimental' gnu.io work. It just happens that the branch is what everyone uses now. checkout -r commapi-0-0-1 rxtx-devel will get the branch On Sun, 5 Apr 2009, cowwoc wrote: > Trent Jarvi wrote: >> It will compile with the msvc cl.exe and nmake. See Makefile.msvc in the >> top level directory. You will need to adjust the JAVA_HOME variable. Also >> use the MSVC command prompt for x86_64 so cl and nmake are on your path. > > This is very odd. The CVS version of the code does not contain this > file. Do you keep the latest code somewhere else? > > Gili > From cowwoc at bbs.darktech.org Sun Apr 5 14:50:47 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 16:50:47 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> Message-ID: <49D919A7.1070806@bbs.darktech.org> Okay, I tracked down the crash. It's being caused by YACK() using a 80-character buffer. The error message is longer than 80 characters, so _snprintf_s() crashes to avoid a buffer overflow. Please apply the attached patch and add the zipped up Visual Studio project directory. It's not perfect yet but it's a good start. Gili Trent Jarvi wrote: > > CVS HEAD is currently the rxtx 2.0 code. A branch was created long > ago for 'experimental' gnu.io work. It just happens that the branch > is what everyone uses now. > > checkout -r commapi-0-0-1 rxtx-devel > > will get the branch > > On Sun, 5 Apr 2009, cowwoc wrote: > >> Trent Jarvi wrote: >>> It will compile with the msvc cl.exe and nmake. See Makefile.msvc >>> in the top level directory. You will need to adjust the JAVA_HOME >>> variable. Also use the MSVC command prompt for x86_64 so cl and >>> nmake are on your path. >> >> This is very odd. The CVS version of the code does not contain >> this file. Do you keep the latest code somewhere else? >> >> Gili >> -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx-devel.patch Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20090405/d9b82962/attachment-0004.pl -------------- next part -------------- A non-text attachment was scrubbed... Name: Win32.zip Type: application/octet-stream Size: 17764 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20090405/d9b82962/attachment-0006.obj From cowwoc at bbs.darktech.org Sun Apr 5 15:22:01 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 17:22:01 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D919A7.1070806@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> <49D919A7.1070806@bbs.darktech.org> Message-ID: <49D920F9.6080702@bbs.darktech.org> My mistake. The problem in YACK is real, but it isn't the real cause of the crash. The crash is caused by termios.c line 1099: index->prev->next = port; because in my case "index->prev==0". I think the bug is that the code assumes that index will contain a minimum of two entries if we're inserting a previously closed fd. In my case, it only contains one. I'm not sure why you have this code branch (as opposed to appending to the end of index). Please take a look. Thanks, Gili cowwoc wrote: > > Okay, I tracked down the crash. It's being caused by YACK() using a > 80-character buffer. The error message is longer than 80 characters, so > _snprintf_s() crashes to avoid a buffer overflow. > > Please apply the attached patch and add the zipped up Visual Studio > project directory. It's not perfect yet but it's a good start. > > Gili > > Trent Jarvi wrote: >> >> CVS HEAD is currently the rxtx 2.0 code. A branch was created long >> ago for 'experimental' gnu.io work. It just happens that the branch >> is what everyone uses now. >> >> checkout -r commapi-0-0-1 rxtx-devel >> >> will get the branch >> >> On Sun, 5 Apr 2009, cowwoc wrote: >> >>> Trent Jarvi wrote: >>>> It will compile with the msvc cl.exe and nmake. See Makefile.msvc >>>> in the top level directory. You will need to adjust the JAVA_HOME >>>> variable. Also use the MSVC command prompt for x86_64 so cl and >>>> nmake are on your path. >>> >>> This is very odd. The CVS version of the code does not contain >>> this file. Do you keep the latest code somewhere else? >>> >>> Gili >>> From tjarvi at qbang.org Sun Apr 5 16:13:27 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Apr 2009 16:13:27 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D920F9.6080702@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> <49D919A7.1070806@bbs.darktech.org> <49D920F9.6080702@bbs.darktech.org> Message-ID: Hi Gili, Are you using the cvs version? I thought we fixed the linked list issues. A solution was posted to the list. Let me look at work tomorrow to see what I have. On Sun, 5 Apr 2009, cowwoc wrote: > > My mistake. The problem in YACK is real, but it isn't the real cause > of the crash. The crash is caused by termios.c line 1099: > > index->prev->next = port; > > because in my case "index->prev==0". I think the bug is that the code > assumes that index will contain a minimum of two entries if we're inserting a > previously closed fd. In my case, it only contains one. > > I'm not sure why you have this code branch (as opposed to appending > to the end of index). Please take a look. > > Thanks, > Gili > > cowwoc wrote: >> >> Okay, I tracked down the crash. It's being caused by YACK() using a >> 80-character buffer. The error message is longer than 80 characters, so >> _snprintf_s() crashes to avoid a buffer overflow. >> >> Please apply the attached patch and add the zipped up Visual Studio >> project directory. It's not perfect yet but it's a good start. >> >> Gili >> >> Trent Jarvi wrote: >>> >>> CVS HEAD is currently the rxtx 2.0 code. A branch was created long ago >>> for 'experimental' gnu.io work. It just happens that the branch is what >>> everyone uses now. >>> >>> checkout -r commapi-0-0-1 rxtx-devel >>> >>> will get the branch >>> >>> On Sun, 5 Apr 2009, cowwoc wrote: >>> >>>> Trent Jarvi wrote: >>>>> It will compile with the msvc cl.exe and nmake. See Makefile.msvc in >>>>> the top level directory. You will need to adjust the JAVA_HOME >>>>> variable. Also use the MSVC command prompt for x86_64 so cl and nmake >>>>> are on your path. >>>> >>>> This is very odd. The CVS version of the code does not contain this >>>> file. Do you keep the latest code somewhere else? >>>> >>>> Gili >>>> > From ilkka at myller.com Sun Apr 5 23:58:08 2009 From: ilkka at myller.com (Ilkka Myller) Date: Mon, 6 Apr 2009 08:58:08 +0300 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> <49D919A7.1070806@bbs.darktech.org> <49D920F9.6080702@bbs.darktech.org> Message-ID: <19779C97-E0C7-4E3D-B715-F84F50F00CE6@myller.com> Hi all, I've already submitted the patch to fix this issue in february: http://mailman.qbang.org/pipermail/rxtx/2009-February/3989441.html The patch fixes the mentioned doubly linked list handling in termios.c -- I Trent Jarvi kirjoitti 6.4.2009 kello 1.13: > > Hi Gili, > > Are you using the cvs version? I thought we fixed the linked list > issues. > A solution was posted to the list. Let me look at work tomorrow to > see > what I have. > > > > On Sun, 5 Apr 2009, cowwoc wrote: > >> >> My mistake. The problem in YACK is real, but it isn't the real cause >> of the crash. The crash is caused by termios.c line 1099: >> >> index->prev->next = port; >> >> because in my case "index->prev==0". I think the bug is that the >> code >> assumes that index will contain a minimum of two entries if we're >> inserting a >> previously closed fd. In my case, it only contains one. >> >> I'm not sure why you have this code branch (as opposed to appending >> to the end of index). Please take a look. >> >> Thanks, >> Gili >> >> cowwoc wrote: >>> >>> Okay, I tracked down the crash. It's being caused by YACK() >>> using a >>> 80-character buffer. The error message is longer than 80 >>> characters, so >>> _snprintf_s() crashes to avoid a buffer overflow. >>> >>> Please apply the attached patch and add the zipped up Visual >>> Studio >>> project directory. It's not perfect yet but it's a good start. >>> >>> Gili >>> >>> Trent Jarvi wrote: >>>> >>>> CVS HEAD is currently the rxtx 2.0 code. A branch was created >>>> long ago >>>> for 'experimental' gnu.io work. It just happens that the branch >>>> is what >>>> everyone uses now. >>>> >>>> checkout -r commapi-0-0-1 rxtx-devel >>>> >>>> will get the branch >>>> >>>> On Sun, 5 Apr 2009, cowwoc wrote: >>>> >>>>> Trent Jarvi wrote: >>>>>> It will compile with the msvc cl.exe and nmake. See >>>>>> Makefile.msvc in >>>>>> the top level directory. You will need to adjust the JAVA_HOME >>>>>> variable. Also use the MSVC command prompt for x86_64 so cl and >>>>>> nmake >>>>>> are on your path. >>>>> >>>>> This is very odd. The CVS version of the code does not >>>>> contain this >>>>> file. Do you keep the latest code somewhere else? >>>>> >>>>> Gili >>>>> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Steffen.DETTMER at ingenico.com Mon Apr 6 02:53:47 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 6 Apr 2009 10:53:47 +0200 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D919A7.1070806@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> <49D919A7.1070806@bbs.darktech.org> Message-ID: <20090406085347.GM8289@elberon.bln.de.ingenico.com> Hi, just two minor details, first about the errno change, I though #include extern int errno; is correct (POSIX.1) - why this change? second about the log message, I think the maximum length could be limited and the return value of malloc must be checked for != NULL before using. Should it be _snprintf_s( message, 80, _TRUNCATE, "Error 0x%x at %s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); (I know that MS-CRT _snprintf does not guarantee to have a final EOS, but I think _snprintf_s with _TRUNCATE does so?). If it is known that truncation may happen maybe sizeof[message] could be increased; maybe using some %.20s could be used avoiding __FILE__ including big pathes to a message where all the message had been cut-off. To have it portable I think it could be: /* generally: */ #if defined(_MSC_VER) # define snprintf _snprintf #endif snprintf(message, sizeof(message), "Error 0x%x at %.20s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); message[sizeof(message)-1] = '\0'; /* needed for MS CRT snprintf */ (for length and size parameter I think size_t could be an option, but on several platforms, including MS-CRT and older glibc, there is no %z, unfortunately) oki, Steffen * cowwoc wrote on Sun, Apr 05, 2009 at 16:50 -0400: > > Okay, I tracked down the crash. It's being caused by YACK() using a > 80-character buffer. The error message is longer than 80 characters, so > _snprintf_s() crashes to avoid a buffer overflow. > > Please apply the attached patch and add the zipped up Visual Studio > project directory. It's not perfect yet but it's a good start. > > Gili > > Trent Jarvi wrote: > > > >CVS HEAD is currently the rxtx 2.0 code. A branch was created long > >ago for 'experimental' gnu.io work. It just happens that the branch > >is what everyone uses now. > > > >checkout -r commapi-0-0-1 rxtx-devel > > > >will get the branch > > > >On Sun, 5 Apr 2009, cowwoc wrote: > > > >>Trent Jarvi wrote: > >>>It will compile with the msvc cl.exe and nmake. See Makefile.msvc > >>>in the top level directory. You will need to adjust the JAVA_HOME > >>>variable. Also use the MSVC command prompt for x86_64 so cl and > >>>nmake are on your path. > >> > >> This is very odd. The CVS version of the code does not contain > >>this file. Do you keep the latest code somewhere else? > >> > >>Gili > >> > Index: ParallelImp.c > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/ParallelImp.c,v > retrieving revision 1.15.2.36 > diff -u -r1.15.2.36 ParallelImp.c > --- ParallelImp.c 11 Feb 2009 01:04:19 -0000 1.15.2.36 > +++ ParallelImp.c 5 Apr 2009 17:55:23 -0000 > @@ -119,7 +119,7 @@ > # include > #endif > > -extern int errno; > +_CRTIMP extern int * __cdecl _errno(void); > > #include "ParallelImp.h" > > @@ -181,8 +181,6 @@ > > #if defined (WIN32) > > -#define CTL_CODE( DeviceType, Function, Method, Access ) (((DeviceType) << 16) | ((Access) << 14) | ((Function) << 2) | (Method)) > - > #define FILE_DEVICE_PARALLEL_PORT 0x00000016 > #define METHOD_BUFFERED 0 > #define FILE_ANY_ACCESS 0 > @@ -253,7 +251,6 @@ > jobject jobj) > { > int fd = get_java_var( env, jobj,"fd","I" ); > - int status; > #if defined (__linux__) > ioctl(fd, LPGETSTATUS, &status); > #elif defined (WIN32) > Index: SerialImp.c > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v > retrieving revision 1.46.2.203 > diff -u -r1.46.2.203 SerialImp.c > --- SerialImp.c 19 Mar 2009 03:27:48 -0000 1.46.2.203 > +++ SerialImp.c 5 Apr 2009 17:49:48 -0000 > @@ -147,7 +147,7 @@ > #include > #endif /* LIBLOCKDEV */ > > -extern int errno; > +_CRTIMP extern int * __cdecl _errno(void); > > #include "SerialImp.h" > > Index: termios.c > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/termios.c,v > retrieving revision 1.9.2.62 > diff -u -r1.9.2.62 termios.c > --- termios.c 13 Jan 2009 03:08:55 -0000 1.9.2.62 > +++ termios.c 5 Apr 2009 17:54:09 -0000 > @@ -88,7 +88,7 @@ > #define SIGIO 0 > > int my_errno; > -extern int errno; > +_CRTIMP extern int * __cdecl _errno(void); > struct termios_list > { > char filename[80]; > @@ -1350,7 +1350,7 @@ > In that case use EAGAIN. See SerialImp.c:testRead() > ----------------------------------------------------------*/ > > -int serial_read( int fd, void *vb, int size ) > +int serial_read( int fd, void *vb, unsigned int size ) > { > long start, now; > unsigned long nBytes = 0, total = 0, error; > Index: win32termios.h > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/win32termios.h,v > retrieving revision 1.5.2.34 > diff -u -r1.5.2.34 win32termios.h > --- win32termios.h 5 Feb 2009 01:25:05 -0000 1.5.2.34 > +++ win32termios.h 5 Apr 2009 20:29:30 -0000 > @@ -60,6 +60,7 @@ > #include > #include > #include > +#include > #ifdef TRACE > #define ENTER(x) report("entering "x" \n"); > #define LEAVE(x) report("leaving "x" \n"); > @@ -70,8 +71,9 @@ > #if defined(_MSC_VER) > #define YACK() \ > { \ > - char *allocTextBuf, message[80]; \ > - unsigned long nChars; \ > + char *allocTextBuf, *message; \ > + const unsigned short longestNumber = 20; \ > + unsigned long nChars, len; \ > unsigned int errorCode = GetLastError(); \ > nChars = FormatMessage ( \ > FORMAT_MESSAGE_ALLOCATE_BUFFER | \ > @@ -82,8 +84,12 @@ > (LPSTR)&allocTextBuf, \ > 16, \ > NULL ); \ > - _snprintf_s( message, 80, 80, "Error 0x%x at %s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); \ > + len = strlen("Error 0x") + longestNumber + strlen(" at ") + strlen(__FILE__) + longestNumber + \ > + strlen(": ") + ((nChars+1) * sizeof(TCHAR)) + 1; \ > + message = malloc(len); \ > + _snprintf_s( message, len, len - 1, "Error 0x%x at %s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); \ > report_error( message ); \ > + free(message); \ > LocalFree(allocTextBuf); \ > Sleep(1); \ > } > @@ -173,7 +179,7 @@ > int serial_test( char * ); > int serial_open(const char *File, int flags, ... ); > int serial_close(int fd); > -int serial_read(int fd, void *b, int size); > +int serial_read(int fd, void *b, unsigned int size); > int serial_write(int fd, char *Str, int length); > /* > * lcc winsock.h conflicts > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx End of message. ------------------------------------------------------------------->8======= About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From bill7007 at gmail.com Mon Apr 6 16:34:50 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Mon, 6 Apr 2009 18:34:50 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: <49D693BA.8060909@gatworks.com> References: <49D546F8.20807@gatworks.com> <49D693BA.8060909@gatworks.com> Message-ID: Once it hung, three stack dumps minutes apart were exactly the same. I have a noticed that when it hangs, the read appears after flush() enter and before flush leave() that doesn't happen like: RXTXPort:SerialOutputStream:flush() enter RXTXPort:SerialInputStream:read(8192 0 8192) called When it works, flush() enter and leave happen together. It may just be because flush() hangs and read is the only other thread waiting to run at that point. I don't know much about the RXTX design and kernel interaction, just digging through the code some. Is there a design description somewhere? Am hung up on target system compile since UTS_RELEASE seems no longer defined for 2.6.18 up kernels and have not figured a good patch yet. But, that is another issue. Thanks for the good help. On Fri, Apr 3, 2009 at 6:54 PM, U. George wrote: > I would have tried 2 or 3 "^\" . If things are stuck, then all will be at > same 'java' instruction. If thread is moving, then one of the snapshots > would be different. > > I *think* flushing/draining wont return until the kernel buffers to device > have been accepted by device. Stuck/paused device? > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090406/c4b509d8/attachment-0005.html From tjarvi at qbang.org Mon Apr 6 17:45:38 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 6 Apr 2009 17:45:38 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <20090406085347.GM8289@elberon.bln.de.ingenico.com> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> <49D919A7.1070806@bbs.darktech.org> <20090406085347.GM8289@elberon.bln.de.ingenico.com> Message-ID: The error bits in the patch can probably just be dropped out. I don't see what they solve. Your snprintf define appears to work. The following is what I'd like to put in if noone objects. #if defined(_MSC_VER) # define snprintf _snprintf #endif #define YACK() \ { \ char *allocTextBuf, message[80]; \ unsigned long nChars; \ unsigned int errorCode = GetLastError(); \ nChars = FormatMessage ( \ FORMAT_MESSAGE_ALLOCATE_BUFFER | \ FORMAT_MESSAGE_FROM_SYSTEM, \ NULL, \ errorCode, \ MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT), \ (LPSTR)&allocTextBuf, \ 16, \ NULL ); \ snprintf( message, 80, "Error 0x%x at %s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); \ message[sizeof(message)-1] = '\0'; /* needed for MS CRT snprintf */ \ report_error( message ); \ LocalFree(allocTextBuf); \ Sleep(1); \ } On Mon, 6 Apr 2009, Steffen DETTMER wrote: > Hi, > > just two minor details, first about the errno change, I though > > #include > extern int errno; > > is correct (POSIX.1) - why this change? > > second about the log message, I think the maximum length could be > limited and the return value of malloc must be checked for != > NULL before using. > > Should it be > > _snprintf_s( message, 80, _TRUNCATE, "Error 0x%x at %s(%d): %s\n", > errorCode, __FILE__, __LINE__, allocTextBuf); > > (I know that MS-CRT _snprintf does not guarantee to have a final > EOS, but I think _snprintf_s with _TRUNCATE does so?). > > If it is known that truncation may happen maybe sizeof[message] > could be increased; maybe using some %.20s could be used avoiding > __FILE__ including big pathes to a message where all the message > had been cut-off. > > To have it portable I think it could be: > > /* generally: */ > #if defined(_MSC_VER) > # define snprintf _snprintf > #endif > > snprintf(message, sizeof(message), "Error 0x%x at %.20s(%d): %s\n", > errorCode, __FILE__, __LINE__, allocTextBuf); > message[sizeof(message)-1] = '\0'; /* needed for MS CRT snprintf */ > > (for length and size parameter I think size_t could be an option, > but on several platforms, including MS-CRT and older glibc, > there is no %z, unfortunately) > > oki, > > Steffen > > > * cowwoc wrote on Sun, Apr 05, 2009 at 16:50 -0400: >> >> Okay, I tracked down the crash. It's being caused by YACK() using a >> 80-character buffer. The error message is longer than 80 characters, so >> _snprintf_s() crashes to avoid a buffer overflow. >> >> Please apply the attached patch and add the zipped up Visual Studio >> project directory. It's not perfect yet but it's a good start. >> >> Gili >> >> Trent Jarvi wrote: >> > >> >CVS HEAD is currently the rxtx 2.0 code. A branch was created long >> >ago for 'experimental' gnu.io work. It just happens that the branch >> >is what everyone uses now. >> > >> >checkout -r commapi-0-0-1 rxtx-devel >> > >> >will get the branch >> > >> >On Sun, 5 Apr 2009, cowwoc wrote: >> > >> >>Trent Jarvi wrote: >> >>>It will compile with the msvc cl.exe and nmake. See Makefile.msvc >> >>>in the top level directory. You will need to adjust the JAVA_HOME >> >>>variable. Also use the MSVC command prompt for x86_64 so cl and >> >>>nmake are on your path. >> >> >> >> This is very odd. The CVS version of the code does not contain >> >>this file. Do you keep the latest code somewhere else? >> >> >> >>Gili >> >> > >> Index: ParallelImp.c >> =================================================================== >> RCS file: /usr/local/cvsroot/rxtx-devel/src/ParallelImp.c,v >> retrieving revision 1.15.2.36 >> diff -u -r1.15.2.36 ParallelImp.c >> --- ParallelImp.c 11 Feb 2009 01:04:19 -0000 1.15.2.36 >> +++ ParallelImp.c 5 Apr 2009 17:55:23 -0000 >> @@ -119,7 +119,7 @@ >> # include >> #endif >> >> -extern int errno; >> +_CRTIMP extern int * __cdecl _errno(void); >> >> #include "ParallelImp.h" >> >> @@ -181,8 +181,6 @@ >> >> #if defined (WIN32) >> >> -#define CTL_CODE( DeviceType, Function, Method, Access ) (((DeviceType) << 16) | ((Access) << 14) | ((Function) << 2) | (Method)) >> - >> #define FILE_DEVICE_PARALLEL_PORT 0x00000016 >> #define METHOD_BUFFERED 0 >> #define FILE_ANY_ACCESS 0 >> @@ -253,7 +251,6 @@ >> jobject jobj) >> { >> int fd = get_java_var( env, jobj,"fd","I" ); >> - int status; >> #if defined (__linux__) >> ioctl(fd, LPGETSTATUS, &status); >> #elif defined (WIN32) >> Index: SerialImp.c >> =================================================================== >> RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v >> retrieving revision 1.46.2.203 >> diff -u -r1.46.2.203 SerialImp.c >> --- SerialImp.c 19 Mar 2009 03:27:48 -0000 1.46.2.203 >> +++ SerialImp.c 5 Apr 2009 17:49:48 -0000 >> @@ -147,7 +147,7 @@ >> #include >> #endif /* LIBLOCKDEV */ >> >> -extern int errno; >> +_CRTIMP extern int * __cdecl _errno(void); >> >> #include "SerialImp.h" >> >> Index: termios.c >> =================================================================== >> RCS file: /usr/local/cvsroot/rxtx-devel/src/termios.c,v >> retrieving revision 1.9.2.62 >> diff -u -r1.9.2.62 termios.c >> --- termios.c 13 Jan 2009 03:08:55 -0000 1.9.2.62 >> +++ termios.c 5 Apr 2009 17:54:09 -0000 >> @@ -88,7 +88,7 @@ >> #define SIGIO 0 >> >> int my_errno; >> -extern int errno; >> +_CRTIMP extern int * __cdecl _errno(void); >> struct termios_list >> { >> char filename[80]; >> @@ -1350,7 +1350,7 @@ >> In that case use EAGAIN. See SerialImp.c:testRead() >> ----------------------------------------------------------*/ >> >> -int serial_read( int fd, void *vb, int size ) >> +int serial_read( int fd, void *vb, unsigned int size ) >> { >> long start, now; >> unsigned long nBytes = 0, total = 0, error; >> Index: win32termios.h >> =================================================================== >> RCS file: /usr/local/cvsroot/rxtx-devel/src/win32termios.h,v >> retrieving revision 1.5.2.34 >> diff -u -r1.5.2.34 win32termios.h >> --- win32termios.h 5 Feb 2009 01:25:05 -0000 1.5.2.34 >> +++ win32termios.h 5 Apr 2009 20:29:30 -0000 >> @@ -60,6 +60,7 @@ >> #include >> #include >> #include >> +#include >> #ifdef TRACE >> #define ENTER(x) report("entering "x" \n"); >> #define LEAVE(x) report("leaving "x" \n"); >> @@ -70,8 +71,9 @@ >> #if defined(_MSC_VER) >> #define YACK() \ >> { \ >> - char *allocTextBuf, message[80]; \ >> - unsigned long nChars; \ >> + char *allocTextBuf, *message; \ >> + const unsigned short longestNumber = 20; \ >> + unsigned long nChars, len; \ >> unsigned int errorCode = GetLastError(); \ >> nChars = FormatMessage ( \ >> FORMAT_MESSAGE_ALLOCATE_BUFFER | \ >> @@ -82,8 +84,12 @@ >> (LPSTR)&allocTextBuf, \ >> 16, \ >> NULL ); \ >> - _snprintf_s( message, 80, 80, "Error 0x%x at %s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); \ >> + len = strlen("Error 0x") + longestNumber + strlen(" at ") + strlen(__FILE__) + longestNumber + \ >> + strlen(": ") + ((nChars+1) * sizeof(TCHAR)) + 1; \ >> + message = malloc(len); \ >> + _snprintf_s( message, len, len - 1, "Error 0x%x at %s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); \ >> report_error( message ); \ >> + free(message); \ >> LocalFree(allocTextBuf); \ >> Sleep(1); \ >> } >> @@ -173,7 +179,7 @@ >> int serial_test( char * ); >> int serial_open(const char *File, int flags, ... ); >> int serial_close(int fd); >> -int serial_read(int fd, void *b, int size); >> +int serial_read(int fd, void *b, unsigned int size); >> int serial_write(int fd, char *Str, int length); >> /* >> * lcc winsock.h conflicts >> > > >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > > > > > > > > > > > > End of message. > ------------------------------------------------------------------->8======= > > > About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. > This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > P Please consider the environment before printing this e-mail > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Apr 6 18:11:28 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 6 Apr 2009 18:11:28 -0600 (MDT) Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: <49D546F8.20807@gatworks.com> <49D693BA.8060909@gatworks.com> Message-ID: UTS_RELEASE is defined in now. The check really should be removed from RXTX. It was a defensive check for wilder times when GNU glibc did not have defines the kernel headers had so rxtx would include the kernel headers instead. :/ If you don't have linux/version.h, it is generated when you configure the kernel. make oldconfig used to do the trick. It may make sense to work with the prerelease or CVS code. RXTX just assumes that flush, read and anything else the kernel exposes may be called at anytime from any thread. There isn't a design for the kernel interaction. There are higher level constraints put in Java to prevent some things happening at the same time with 'synchronized.' RXTXPort.java has all of those. When the port is opened, a native event thread is started which uses select to know if an event has happened. BSD like systems have a native thread that fires off on write which tries to flush() to determine when the output buffer is empty asynchronously. The rest is not marshaled in any fashion at the native level. T I think there is a lower level deadlock being triggered in flush as well. I don't think it should be possible if everything was right underneath us. You may want to examine the java code closer to make sure it isnt possible the lock is there. On Mon, 6 Apr 2009, Bill Johnson wrote: > Once it hung, three stack dumps minutes apart were exactly the same. > I have a noticed that when it hangs, the read appears after flush() enter and > before flush leave() that doesn't happen like: > RXTXPort:SerialOutputStream:flush() enter > RXTXPort:SerialInputStream:read(8192 0 8192) called > > When it works, flush() enter and leave happen together. It may just be because > flush() hangs and read is the only other thread waiting to run at that point. > I don't know much about the RXTX design and kernel interaction, just digging > through the code some. Is there a design description somewhere? > > Am hung up on target system compile since UTS_RELEASE seems no longer defined for > 2.6.18 up kernels and have not figured a good patch yet. But, that is another > issue. > > Thanks for the good help. > > > On Fri, Apr 3, 2009 at 6:54 PM, U. George wrote: > I would have tried 2 or 3 "^\" . If things are stuck, then all will be > at same 'java' instruction. If thread is moving, then one of the > snapshots would be different. > > I *think* flushing/draining wont return until the kernel buffers to > device have been accepted by device. Stuck/paused device? > > > > > From tjarvi at qbang.org Mon Apr 6 18:28:50 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 6 Apr 2009 18:28:50 -0600 (MDT) Subject: [Rxtx] CVS updates. Pre3 is comming. Message-ID: I need to go through the bugzilla reports prior to the pre3 release. I think this should be close if you want to check it out from CVS. added: YACK() debug overflow fix for windows Steffen DETTMER (and many others) multiport fix for windows. Ilkka Myller http://mailman.qbang.org/pipermail/rxtx/2009-February/3989441.html I think this code is current. If I missed something, yell. CVS Info: export/setenv CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login # passwd mousy cvs checkout -r commapi-0-0-1 rxtx-devel -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Apr 6 22:32:07 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 6 Apr 2009 22:32:07 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D919A7.1070806@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> <49D919A7.1070806@bbs.darktech.org> Message-ID: Ah. I'll put this in CVS tomorrow. I did sync up the code with my work sandbox today. I just forgot to pull and add this. On Sun, 5 Apr 2009, cowwoc wrote: > > Okay, I tracked down the crash. It's being caused by YACK() using a > 80-character buffer. The error message is longer than 80 characters, so > _snprintf_s() crashes to avoid a buffer overflow. > > Please apply the attached patch and add the zipped up Visual Studio > project directory. It's not perfect yet but it's a good start. > > Gili > > Trent Jarvi wrote: >> >> CVS HEAD is currently the rxtx 2.0 code. A branch was created long ago for >> 'experimental' gnu.io work. It just happens that the branch is what >> everyone uses now. >> >> checkout -r commapi-0-0-1 rxtx-devel >> >> will get the branch >> >> On Sun, 5 Apr 2009, cowwoc wrote: >> >>> Trent Jarvi wrote: >>>> It will compile with the msvc cl.exe and nmake. See Makefile.msvc in the >>>> top level directory. You will need to adjust the JAVA_HOME variable. >>>> Also use the MSVC command prompt for x86_64 so cl and nmake are on your >>>> path. >>> >>> This is very odd. The CVS version of the code does not contain this >>> file. Do you keep the latest code somewhere else? >>> >>> Gili >>> > From cowwoc at bbs.darktech.org Tue Apr 7 06:07:46 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Tue, 07 Apr 2009 08:07:46 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: References: Message-ID: <49DB4212.40807@bbs.darktech.org> > just two minor details, first about the errno change, I though > > #include > extern int errno; > > is correct (POSIX.1) - why this change? If you compile this under Visual Studio 2008 you will get warnings that the errno type being imported is different from the type being exported. The definition I pasted is the one being exported. Perhaps we should use #ifdef WIN32 for this? Gili From bill7007 at gmail.com Tue Apr 7 17:58:54 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Tue, 7 Apr 2009 19:58:54 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: <49D546F8.20807@gatworks.com> <49D693BA.8060909@gatworks.com> Message-ID: I have traced the hang down to a call to tcdrain(fd) in SerialImp.c:drain() running and rebuilt under Netbeans on the target machine with debug messages on. That puts it into the system code, so I'm not sure how to proceed. I guess I could debug into the kernel source but I've not done that. I saw some discussion about an IOCTL that sets/adjusts a timeout on tcdrain() but that may have been for BSD. Maybe there is some new setup requirement or bug introduced with this 2.6.18 kernel or a hardware difference. Below is a message listing with some of the repeated parts removed. Maybe you can see something noteworthy? JNI_OnLoad called. WARNING: RXTX Version mismatch Jar version = RXTX-2.2pre2 native lib Version = RXTX-2.2pre3 entering RXTXCommDriver:getDeviceDirectory entering RXTXPort:testRead fhs_lock: creating lockfile: 29704 fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXPort:testRead RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB2 fhs_lock: creating lockfile: 29704 fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXPort:testRead RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB1 fhs_lock: creating lockfile: 29704 fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXPort:testRead RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB0 fhs_lock: creating lockfile: 29704 fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXPort:testRead fhs_lock: creating lockfile: 29704 ... REPEATS fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXPort:testRead fhs_lock: creating lockfile: 29704 fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXCommDriver:getDeviceDirectory entering RXTXPort:testRead fhs_lock: creating lockfile: 29704 ...REPEATS fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXPort:testRead fhs_lock: creating lockfile: 29704 fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXPort:Initialize RXTX WARNING: This library was compiled to run with OS release 2.6.18 and you are currently running OS release 2.6.18-92.1.6.el5. In some cases this can be a problem. Try recompiling RXTX if you notice strange behavior. If you just compiled RXTX make sure /usr/include/linux is a symbolic link to the include files that came with the kernel source and not an older copy. press enter to continue leaving RXTXPort:Initialize entering RXTXPort:open fhs_lock: creating lockfile: 29704 open: locking worked for /dev/ttyUSB2 open: fd returned is 9 leaving RXTXPort:open entering eventLoop has_line_status_register_acess: Port does not support TIOCSERGETLSR driver_has_tiocgicount: Port does not support TIOCGICOUNT events init_threads: get eis init_threads: set eis init_threads: stop leaving RXTXPort:translate_speed entering RXTXPort:nativeSetSerialPortParams entering translate_date_bits entering translate_stop_bits leaving RXTXPort:translate_stop_bits entering translate_parity leaving translate_parity entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 ...REPEATS entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 leaving RXTXPort:nativeSetSerialPortParams entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 ...REPEATS entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 entering writeArray entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 writeArray() leaving RXTXPort:writeArray entering SerialImp.c:drain() nativeDrain: trying tcdrain RXTXPort:drain() returns: 0 leaving RXTXPort:drain() entering writeArray writeArray() leaving RXTXPort:writeArray entering SerialImp.c:drain() nativeDrain: trying tcdrain entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 Tue Apr 07 18:51:49 EDT 2009:TSerial[22]:Using Port:/dev/ttyUSB2 Tue Apr 07 18:51:49 EDT 2009:TSerial[22].Transmit:TN Tue Apr 07 18:51:49 EDT 2009:TSerial[22].Transmit:RV entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 ...REPEATS FOREVER? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090407/f26e5752/attachment-0004.html From tjarvi at qbang.org Tue Apr 7 18:31:23 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 7 Apr 2009 18:31:23 -0600 (MDT) Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: <49D546F8.20807@gatworks.com> <49D693BA.8060909@gatworks.com> Message-ID: On Tue, 7 Apr 2009, Bill Johnson wrote: > I have traced the hang down to a call to tcdrain(fd) in SerialImp.c:drain() > running and rebuilt under Netbeans on the target machine with debug messages > on. That puts it into the system code, so I'm not sure how to proceed. I > guess I could debug into the kernel source but I've not done that. I saw > some discussion about an IOCTL that sets/adjusts a timeout on tcdrain() but > that may have been for BSD. Maybe there is some new setup requirement or bug > introduced with this 2.6.18 kernel or a hardware difference. > Below is a message listing with some of the repeated parts removed. Maybe > you can see something noteworthy? > > JNI_OnLoad called. > WARNING:? RXTX Version mismatch > ??????? Jar version = RXTX-2.2pre2 > ??????? native lib Version = RXTX-2.2pre3 > entering RXTXCommDriver:getDeviceDirectory > entering RXTXPort:testRead > fhs_lock: creating lockfile:????? 29704 > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXPort:testRead > RXTX Warning:? Removing stale lock file. /var/lock/LCK..ttyUSB2 > fhs_lock: creating lockfile:????? 29704 > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXPort:testRead > RXTX Warning:? Removing stale lock file. /var/lock/LCK..ttyUSB1 > fhs_lock: creating lockfile:????? 29704 > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXPort:testRead > RXTX Warning:? Removing stale lock file. /var/lock/LCK..ttyUSB0 > fhs_lock: creating lockfile:????? 29704 > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXPort:testRead > fhs_lock: creating lockfile:????? 29704 > > ... REPEATS > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXPort:testRead > fhs_lock: creating lockfile:????? 29704 > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXCommDriver:getDeviceDirectory > entering RXTXPort:testRead > fhs_lock: creating lockfile:????? 29704 > > ...REPEATS > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXPort:testRead > fhs_lock: creating lockfile:????? 29704 > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXPort:Initialize > > > > RXTX WARNING:? This library was compiled to run with OS release 2.6.18 and > you are currently running OS release 2.6.18-92.1.6.el5.? In some cases this > can be a problem.? Try recompiling RXTX if you notice strange behavior.? If > you just compiled RXTX make sure /usr/include/linux is a symbolic link to > the include files that came with the kernel source and not an older copy. > > > press enter to continue > > leaving RXTXPort:Initialize > entering RXTXPort:open > fhs_lock: creating lockfile:????? 29704 > > open: locking worked for /dev/ttyUSB2 > open: fd returned is 9 > leaving RXTXPort:open > entering eventLoop > ? > has_line_status_register_acess: Port does not support TIOCSERGETLSR > ?driver_has_tiocgicount:? Port does not support TIOCGICOUNT events > init_threads: get eis > init_threads: set eis > init_threads:? stop > leaving RXTXPort:translate_speed > entering RXTXPort:nativeSetSerialPortParams > entering translate_date_bits > entering translate_stop_bits > leaving RXTXPort:translate_stop_bits > entering translate_parity > leaving translate_parity > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > ...REPEATS > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > leaving RXTXPort:nativeSetSerialPortParams > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > ...REPEATS > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > entering writeArray > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > writeArray() > leaving RXTXPort:writeArray > entering SerialImp.c:drain() > nativeDrain: trying tcdrain > RXTXPort:drain() returns: 0 > leaving RXTXPort:drain() > entering writeArray > writeArray() > leaving RXTXPort:writeArray > entering SerialImp.c:drain() > nativeDrain: trying tcdrain > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > Tue Apr 07 18:51:49 EDT 2009:TSerial[22]:Using Port:/dev/ttyUSB2 > Tue Apr 07 18:51:49 EDT 2009:TSerial[22].Transmit:TN > > Tue Apr 07 18:51:49 EDT 2009:TSerial[22].Transmit:RV > > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > ...REPEATS FOREVER? > > > Hi Bill ugh. The tiocmget... is the eventLoop checking for events. It sits with select() but has a timeout value to keep it spinning at a trivial rate. tcdrain() is the suspect. I don't see anything in the code that looks like a problem. If flow control is not enabled, I don't see a reason for it not to return. Given that this is USB, perhaps a message from the device got lost. Onboard UARTs would have a status register change when output buffer is empty. USB needs to communicate the event as an HID device which may be the source of the error. Dropping back to onboard UARTs eliminates that portion of the mix. What vendor/chipset is the USB dongle? I understand code has been pushed upon the linux serial devices for new for things like acpi. There very well could be a bug introduced. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Apr 7 18:38:22 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 7 Apr 2009 18:38:22 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49DB4212.40807@bbs.darktech.org> References: <49DB4212.40807@bbs.darktech.org> Message-ID: On Tue, 7 Apr 2009, cowwoc wrote: >> just two minor details, first about the errno change, I though >> >> #include >> extern int errno; >> >> is correct (POSIX.1) - why this change? > > If you compile this under Visual Studio 2008 you will get warnings that > the errno type being imported is different from the type being exported. > The definition I pasted is the one being exported. Perhaps we should use > #ifdef WIN32 for this? > Hi Gili, Perhaps a workaround for _MSVC is in order. GNU compilers for windows won't complain. If it's a question of MSVC or POSIX being right, the library favors the standard as a stated goal. I'm not sure what MSVC is using errno for but it should not be using it except with POSIX extensions. Perhaps #undef is enough to get rid of the warning and (maybe) has no ill consequences. Newer windows have POSIX extensions that may show how Microsoft solved the problem. It can probably fester. -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Tue Apr 7 19:54:06 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Tue, 07 Apr 2009 21:54:06 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: References: <49DB4212.40807@bbs.darktech.org> Message-ID: <49DC03BE.5010203@bbs.darktech.org> Trent Jarvi wrote: > I'm not sure what MSVC is using errno for but it should not be using it > except with POSIX extensions. Perhaps #undef is enough to get rid of > the warning and (maybe) has no ill consequences. Newer windows have > POSIX extensions that may show how Microsoft solved the problem. > > It can probably fester. What does "newer windows" refer to in this case? I was compiling using Visual Studio 2008 sp1 under Windows Vista. Both are cutting edge technologies as far as official releases go. I think you're best suited to judge whether this warning is a big deal or not so I think you should see it for yourself. Please try firing up Visual Studio 2008 (express?) against the project I sent you. Gili From Steffen.DETTMER at ingenico.com Wed Apr 8 05:50:42 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 8 Apr 2009 13:50:42 +0200 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49DC03BE.5010203@bbs.darktech.org> References: <49DB4212.40807@bbs.darktech.org> <49DC03BE.5010203@bbs.darktech.org> Message-ID: <20090408115042.GC5090@elberon.bln.de.ingenico.com> * cowwoc wrote on Tue, Apr 07, 2009 at 21:54 -0400: > Trent Jarvi wrote: > > I'm not sure what MSVC is using errno for but it should not be using it > > except with POSIX extensions. Perhaps #undef is enough to get rid of > > the warning and (maybe) has no ill consequences. Newer windows have > > POSIX extensions that may show how Microsoft solved the problem. I think here best is simply to omit this old^Wclassic `extern int errno;' line completely. I think standards just say something like `implementations may support the declaration extern int errno;'. About POSIX extensions I think in general it should be considered that althrough many things are available, even with MS Visual C++, the Microsoft tools lead developers to write non-portable code (and personally I think this is intentional). For example, they call the official ISO-C function `strerror' deprecated (!) and twaddle about some security enhancements (without even beeing specific). Someone could, because of this, lead to use the MS specific, unportable `strerror_s' instead. Even better, at _strerror_s they tell, for `ANSI compatiblity someone should use strerror_s'. Of course a program using [_]strerror_s won't be ANSI-C compliant. Do they mean strerror_r? _strerror_s has the same parameters - but of course in different order - to make porting a pain... SCNR. > What does "newer windows" refer to in this case? I was compiling using > Visual Studio 2008 sp1 under Windows Vista. Both are cutting edge > technologies as far as official releases go. `cutting edge technologies' yeah post-standard, portability-cutting technologies smoothing the way to MS world domination; own post-ANSI-C programming languages help (maybe to increase the share holder value)... SCNR. > I think you're best suited to judge whether this warning is a big deal > or not so I think you should see it for yourself. Please try firing up > Visual Studio 2008 (express?) against the project I sent you. yeah, getting the CL.EXE of 2008 running in a normal command line environment (without its special `C++ Shell') is a bit tricky - but possible. ;) oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From tjarvi at qbang.org Wed Apr 8 14:29:54 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 8 Apr 2009 14:29:54 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49DC03BE.5010203@bbs.darktech.org> References: <49DB4212.40807@bbs.darktech.org> <49DC03BE.5010203@bbs.darktech.org> Message-ID: The support has been around for a long time to. I don't know the details but the support appears to be tied to the OS. http://en.wikipedia.org/wiki/POSIX#POSIX_for_Windows On Tue, 7 Apr 2009, cowwoc wrote: > Trent Jarvi wrote: >> I'm not sure what MSVC is using errno for but it should not be using it >> except with POSIX extensions. Perhaps #undef is enough to get rid of the >> warning and (maybe) has no ill consequences. Newer windows have POSIX >> extensions that may show how Microsoft solved the problem. >> >> It can probably fester. > > What does "newer windows" refer to in this case? I was compiling > using Visual Studio 2008 sp1 under Windows Vista. Both are cutting edge > technologies as far as official releases go. > > I think you're best suited to judge whether this warning is a big > deal or not so I think you should see it for yourself. Please try firing up > Visual Studio 2008 (express?) against the project I sent you. > > Gili > From bill7007 at gmail.com Wed Apr 8 15:59:08 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Wed, 8 Apr 2009 17:59:08 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: <49D546F8.20807@gatworks.com> <49D693BA.8060909@gatworks.com> Message-ID: Hi Trent, I think I have hit on a work around but don't know why it works. The USB serial adapter is a "CableMAX" based on Prolific's PL2303. Backing out to the big picture, the application is old and has been very reliable until put on a new cpu and kernel. It only hangs sometimes say 25% and always at the same place, at tcdrain() on the flush() after the second write after startup. If it made it past this stage, all transmit and receive seemed reliable so it was like a startup timing issue. Since learning to debug kernel code is beyond my immediate priority, I took a shot at moving code around, adding delays, and such. I have found it good practice to do a flush after every write on streams like: outputStream.write(data.getBytes()); outputStream.flush(); If I remove the flush() after each write, the problem appears to go away! I don't think the flush is needed for a SerialOutputStream for this application anyway. Thanks for all the help, +BillJ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090408/35d96a9d/attachment-0002.html From bill7007 at gmail.com Thu Apr 9 09:20:11 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Thu, 9 Apr 2009 11:20:11 -0400 Subject: [Rxtx] Baud rate fixes in 2.2pre2 breaks 38400 on some Linux devices Message-ID: Hello, An application that worked at 38400 on a USB serial adapter (PL2303) using 2.1-7-r2 on Linux EL4 (and EL5) now fails using 2.2pre2. serialPort.setSerialPortParams(38400,SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); throws an unsupportedCommOperationException This problem matched a description of Bug 113and I posted a proposed patch there, but I don't understand the whole custom baud rate patch so it may need some thought. An older patch, [Rxtx] [Patch]: Baud Rate fixes try 1, testing encouraged., fixed some custom baud rates but apparently broke 38400 on some Linux device. Other baud rates seem to work OK. And, 38400 tested OK on local non-USB ports. My proposed patch probably breaks the custom baud rate patch since it was keyed on 38400 as a special case for Linux and my fix was to back out part of that patch, specifically: #if defined(TIOCGSERIAL) if ( cspeed == B38400 ) cspeed = 38400; #endif /* TIOCGSERIAL */ +BillJ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090409/5636af64/attachment-0001.html From cowwoc at bbs.darktech.org Fri Apr 10 08:38:49 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Fri, 10 Apr 2009 10:38:49 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: References: <49DB4212.40807@bbs.darktech.org> <49DC03BE.5010203@bbs.darktech.org> Message-ID: <49DF59F9.2050408@bbs.darktech.org> Doesn't Wikipedia list as an optional sub-system? Gili Trent Jarvi wrote: > > The support has been around for a long time to. I don't know the > details but the support appears to be tied to the OS. > > http://en.wikipedia.org/wiki/POSIX#POSIX_for_Windows > > On Tue, 7 Apr 2009, cowwoc wrote: > >> Trent Jarvi wrote: >>> I'm not sure what MSVC is using errno for but it should not be using >>> it except with POSIX extensions. Perhaps #undef is enough to get >>> rid of the warning and (maybe) has no ill consequences. Newer >>> windows have POSIX extensions that may show how Microsoft solved the >>> problem. >>> >>> It can probably fester. >> >> What does "newer windows" refer to in this case? I was compiling >> using Visual Studio 2008 sp1 under Windows Vista. Both are cutting >> edge technologies as far as official releases go. >> >> I think you're best suited to judge whether this warning is a big >> deal or not so I think you should see it for yourself. Please try >> firing up Visual Studio 2008 (express?) against the project I sent you. >> >> Gili >> From cowwoc at bbs.darktech.org Wed Apr 1 22:05:13 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Thu, 02 Apr 2009 00:05:13 -0400 Subject: [Rxtx] Windows 64-bit support? Message-ID: <49D43979.4050702@bbs.darktech.org> Hi, I'd like to run RXTX under the Windows 64-bit JVM. Are there plans to release an official 64-bit version anytime soon? Gili From bill7007 at gmail.com Thu Apr 2 16:01:17 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Thu, 2 Apr 2009 18:01:17 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel Message-ID: Hi, I have an rxtx serial application that used to work reliably until I had to move it to newer hardware and kernel. Now, the application sometimes hangs near first port use. When it does hang, it can be released by starting a second copy of the application which is locked out of the ports but does release the first process. Upgraded from rxtx-2.1-7-r2 to rxtx-2.2pre2 but still hangs. Tried to rebuild on the target machine and ran into the 'UTS_RELEASE' undeclared problem so holding on that approach. Recompiled OK on a 2.6.9-42.0.3.ELsmp system. Debug messages were turned on using: "./configure --enable-DEBUG" and modified RXTXPort.java with: "debug = true;" "z = new Zystem(Zystem.PRINT_MODE);" Below is capture of the application with debugging enabled. It show the application hang point, and the second application's printout at the release point. (pre3 is the locally modified version of pre2) Any suggestions on how to pin this down further? Thanks, +BillJ $ java -version java version "1.5.0_06" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05) Java HotSpot(TM) Client VM (build 1.5.0_06-b05, mixed mode, sharing) $ uname -a Linux qms4 2.6.18-92.1.6.el5 #1 SMP Wed Jun 25 13:49:24 EDT 2008 i686 i686 i386 GNU/Linux ***CAPTURE: [qms at qms4 ~]$ ./qms/ScriptFiles/startup.sh Thu Apr 02 13:35:45 EDT 2009:Setting Log File to:/home/qms/qms/QMS.log Thu Apr 02 13:35:45 EDT 2009:TSettings.HandleIni:ReUsing Ini file:/home/qms/qms/qms.properties WARNING: RXTX Version mismatch Jar version = RXTX-2.2pre2 native lib Version = RXTX-2.2pre3 fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB2 fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB1 fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB0 fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile RXTXPort {} RXTX WARNING: This library was compiled to run with OS release 2.4.20 and you are currently running OS release 2.6.18-92.1.6.el5. In some cases this can be a problem. Try recompiling RXTX if you notice strange behavior. If you just compiled RXTX make sure /usr/include/linux is a symbolic link to the include files that came with the kernel source and not an older copy. press enter to continue RXTXPort:RXTXPort(/dev/ttyUSB2) called fhs_lock: creating lockfile: 10127 open: locking worked for /dev/ttyUSB2 open: fd returned is 8 RXTXPort:MontitorThread:MonitorThread() RXTXPort:MontitorThread:run() has_line_status_register_acess: Port does not support TIOCSERGETLSR init_threads: get eis init_threads: set eis init_threads: stop RXTXPort:RXTXPort(/dev/ttyUSB2) returns with fd = 8 RXTXPort:setSerialPortParams(38400 8 1 0) called RXTXPort:setSerialPortParams(38400 8 1 0) returning RXTXPort:getInputStream() called and returning Thu Apr 02 13:36:02 EDT 2009:TSerial[22]:Using Port:/dev/ttyUSB2 RXTXPort:getOutputStream() called and returning Thu Apr 02 13:36:02 EDT 2009:TSerial[22].Transmit:TN Entering RXTXPort:SerialOutputStream:write(4) writeArray() Leaving RXTXPort:SerialOutputStream:write(4) RXTXPort:SerialOutputStream:flush() enter RXTXPort:SerialOutputStream:flush() leave Thu Apr 02 13:36:02 EDT 2009:TSerial[22].Transmit:RV Entering RXTXPort:SerialOutputStream:write(4) writeArray() Leaving RXTXPort:SerialOutputStream:write(4) RXTXPort:SerialOutputStream:flush() enter RXTXPort:SerialInputStream:read(8192 0 8192) called ***FIRST PROCESS HANGS HERE ***THEN PROCEEDS AFTER SECOND PROCESS STARTS RXTXPort:SerialOutputStream:flush() leave Thu Apr 02 13:41:29 EDT 2009:TSerial[22].Transmit:IH9 Entering RXTXPort:SerialOutputStream:write(5) writeArray() Leaving RXTXPort:SerialOutputStream:write(5) RXTXPort:SerialOutputStream:flush() enter RXTXPort:SerialOutputStream:flush() leave Thu Apr 02 13:41:29 EDT 2009:TSerial[22].Transmit:IL11 ***END CAPTURE ***CAPTURE SECOND PROCESS FAILS OPEN [qms at qms4 ~]$ ./qms/ScriptFiles/startup.sh Thu Apr 02 13:41:27 EDT 2009:Setting Log File to:/home/qms/qms/QMS.log Thu Apr 02 13:41:27 EDT 2009:TSettings.HandleIni:ReUsing Ini file:/home/qms/qms/qms.properties WARNING: RXTX Version mismatch Jar version = RXTX-2.2pre2 native lib Version = RXTX-2.2pre3 fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB2: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB1: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB0: File exists fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB2: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB1: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB0: File exists fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile Thu Apr 02 13:41:30 EDT 2009:TIOBoard: java.io.IOException: java.io.IOException: TSerial[22]: Open Failed ***END CAPTURE -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090402/c66f8d70/attachment-0010.html From netbeans at gatworks.com Thu Apr 2 17:15:04 2009 From: netbeans at gatworks.com (U. George) Date: Thu, 02 Apr 2009 19:15:04 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: Message-ID: <49D546F8.20807@gatworks.com> > "z = new Zystem(Zystem.PRINT_MODE);" > Below is capture of the application with debugging enabled. It show > the application hang point, and the second application's printout at the > release point. (pre3 is the locally modified version of pre2) > Any suggestions on how to pin this down further? > Thanks, > +BillJ When perceived runability is hung, try a ^\ ( control \) on console. This gets the JVM to dump the stacks of all the java threads. If you know the thread that is stuck, then u can see what java statement its stuck at. From tjarvi at qbang.org Thu Apr 2 19:25:17 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 2 Apr 2009 19:25:17 -0600 (MDT) Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: <49D546F8.20807@gatworks.com> References: <49D546F8.20807@gatworks.com> Message-ID: On Thu, 2 Apr 2009, U. George wrote: >> "z = new Zystem(Zystem.PRINT_MODE);" >> Below is capture of the application with debugging enabled. It show >> the application hang point, and the second application's printout at the >> release point. (pre3 is the locally modified version of pre2) >> Any suggestions on how to pin this down further? >> Thanks, >> +BillJ > > When perceived runability is hung, try a ^\ ( control \) on console. > This gets the JVM to dump the stacks of all the java threads. > If you know the thread that is stuck, then u can see what java statement > its stuck at. I've also noticed some linux systems hanging with open/read/write and saw kacpid storms. I need to look at it more but did observe kacpid consuming a core and not returning to a normal state for a significant period of time. It was easy to observe from top sorted by CPU usage. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Apr 2 19:26:18 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 2 Apr 2009 19:26:18 -0600 (MDT) Subject: [Rxtx] Windows 64-bit support? In-Reply-To: <49D43979.4050702@bbs.darktech.org> References: <49D43979.4050702@bbs.darktech.org> Message-ID: On Thu, 2 Apr 2009, cowwoc wrote: > Hi, > > I'd like to run RXTX under the Windows 64-bit JVM. Are there plans > to release an official 64-bit version anytime soon? > It is in the prerelease and will be in the final release. I'm pushing it through as fast as I can in my free time. -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Thu Apr 2 22:57:34 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Fri, 03 Apr 2009 00:57:34 -0400 Subject: [Rxtx] Missing documentation In-Reply-To: References: <49D43979.4050702@bbs.darktech.org> Message-ID: <49D5973E.4050400@bbs.darktech.org> Hi, I noticed that RXTX 2.1 drops javax.comm support in favor of gnu.io. I have one major problem with this: the gui.io.* documentation is very poor. Many classes and methods have no Javadoc at all which makes them difficult to use. Please fix this for the final release. Thank you, Gili From alex.sas at freemail.hu Fri Apr 3 01:36:54 2009 From: alex.sas at freemail.hu (Sas Alex) Date: Fri, 3 Apr 2009 09:36:54 +0200 (CEST) Subject: [Rxtx] Serial port false reads Message-ID: Hi all, On Windows XP, using rxtx-2.1-7-r2 I have a program communicating on a serial line like the following (excerpt): { os.write(command); os.flush(); // Thread.sleep(period); // read response while(is.available() > 0) { is.read() } } If there is a sleep between the os.flush and the reading cycle the correct answer is received. Otherwise (sometimes) there are extra, erronous characters at the beginning of the answer, but the correct answer (according to the protocol) also arrives, afterwards. Is this a normal behaviour, one should wait before the read? If yes, is there a way to determine the minimum amount of time to wait for? Serial port params are: 9600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE. Thank you in advance, Alex ________________________________________________________ El?foglal?si akci? meghosszabb?tva! Korfui ?d?l?s m?r 56.910 Ft-t?l. http://www.budavartours.hu/gorogorszag/?utm_campaign=origo&utm_source=freemail_kimeno_090403&utm_medium=ct&utm_content=korfu_elofoglalasi_akcio#reg_Korfu -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090403/8f3650ea/attachment-0010.html From bill7007 at gmail.com Fri Apr 3 16:15:30 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Fri, 3 Apr 2009 18:15:30 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: <49D546F8.20807@gatworks.com> Message-ID: > When perceived runability is hung, try a ^\ ( control \) on console. >> This gets the JVM to dump the stacks of all the java threads. > > Good idea... A thread dump is below, it looks like only some system threads are in wait state which is probably normal. The "main" thread is stopped writing the first data out the serial port which should complete but its has stopped at: at gnu.io.RXTXPort.nativeDrain(Native Method) It show its state as runnable though. There is another thread, "SerialReader_22", that is waiting to read any data on the same port. I'll bring the app up under Netbeans debugger next. >> > I've also noticed some linux systems hanging with open/read/write and saw > kacpid storms. No CPU use going when it hangs, acts like a deadlock. THREAD DUMP AT HANG: Entering RXTXPort:SerialOutputStream:write(4) writeArray() Leaving RXTXPort:SerialOutputStream:write(4) RXTXPort:SerialOutputStream:flush() enter RXTXPort:SerialInputStream:read(8192 0 8192) called Full thread dump Java HotSpot(TM) Client VM (1.5.0_06-b05 mixed mode, sharing): "SerialReader_22" daemon prio=1 tid=0x087abf38 nid=0x3c8b runnable [0xb1a43000..0xb1a43f30] at gnu.io.RXTXPort.readArray(Native Method) at gnu.io.RXTXPort$SerialInputStream.read(RXTXPort.java:1454) - locked <0x88ca55b8> (a gnu.io.RXTXPort$SerialInputStream) at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:411) at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) - locked <0x88cab378> (a java.io.InputStreamReader) at java.io.InputStreamReader.read(InputStreamReader.java:167) at java.io.BufferedReader.fill(BufferedReader.java:136) at java.io.BufferedReader.readLine(BufferedReader.java:299) - locked <0x88cab378> (a java.io.InputStreamReader) at java.io.BufferedReader.readLine(BufferedReader.java:362) at qms.TSerialPort$SerialRead.run(TSerialPort.java:268) at java.lang.Thread.run(Thread.java:595) "Thread-1" prio=1 tid=0x08a43360 nid=0x3c8a runnable [0xb1ac4000..0xb1ac4db0] at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1641) "AWT-XAWT" daemon prio=1 tid=0x08acc848 nid=0x3c87 runnable [0xb1b45000..0xb1b45e30] at sun.awt.X11.XToolkit.waitForEvents(Native Method) at sun.awt.X11.XToolkit.run(XToolkit.java:463) at sun.awt.X11.XToolkit.run(XToolkit.java:438) at java.lang.Thread.run(Thread.java:595) "Java2D Disposer" daemon prio=1 tid=0x08ab9d30 nid=0x3c86 in Object.wait() [0xb1bc6000..0xb1bc70b0] at java.lang.Object.wait(Native Method) - waiting on <0x8917b110> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:116) - locked <0x8917b110> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:132) at sun.java2d.Disposer.run(Disposer.java:107) at java.lang.Thread.run(Thread.java:595) "Low Memory Detector" daemon prio=1 tid=0x087bea68 nid=0x3c84 runnable [0x00000000..0x00000000] "CompilerThread0" daemon prio=1 tid=0x087bd4c0 nid=0x3c83 waiting on condition [0x00000000..0xb23a7a18] "Signal Dispatcher" daemon prio=1 tid=0x087bc520 nid=0x3c82 runnable [0x00000000..0x00000000] "Finalizer" daemon prio=1 tid=0x087b5710 nid=0x3c81 in Object.wait() [0xb26a9000..0xb26a9f30] at java.lang.Object.wait(Native Method) - waiting on <0x8914a770> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:116) - locked <0x8914a770> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:132) at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159) "Reference Handler" daemon prio=1 tid=0x087b49c8 nid=0x3c80 in Object.wait() [0xb272a000..0xb272adb0] at java.lang.Object.wait(Native Method) - waiting on <0x8914a7f0> (a java.lang.ref.Reference$Lock) at java.lang.Object.wait(Object.java:474) at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116) - locked <0x8914a7f0> (a java.lang.ref.Reference$Lock) "main" prio=1 tid=0x08777b88 nid=0x3c7e runnable [0xbffa7000..0xbffa74f8] at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1248) at qms.TSerialPort.Transmit(TSerialPort.java:192) - locked <0x88c99a68> (a qms.TSerialPort) at qms.TIOBoard.GetIOBoardVersion(TIOBoard.java:168) at qms.TIOBoard.(TIOBoard.java:73) at qms.TQMS.(TQMS.java:47) at qms.MainForm.(MainForm.java:2076) at qms.MainForm.main(MainForm.java:2099) "VM Thread" prio=1 tid=0x087b1e20 nid=0x3c7f runnable "VM Periodic Task Thread" prio=1 tid=0x087bff50 nid=0x3c85 waiting on condition -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090403/20b7bca4/attachment-0009.html From Martin.Oberhuber at windriver.com Fri Apr 3 16:23:43 2009 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Sat, 4 Apr 2009 00:23:43 +0200 Subject: [Rxtx] Missing documentation In-Reply-To: <49D5973E.4050400@bbs.darktech.org> References: <49D43979.4050702@bbs.darktech.org> <49D5973E.4050400@bbs.darktech.org> Message-ID: <460801A4097E3D4CA04CC64EE648584809C8BD6F@ism-mail03.corp.ad.wrs.com> Hello Gili, The classes in the gnu.io namespace are designed to work exactly as their counterparts in the javax.comm namespace. Therefore, if you just take the javax.comm Javadocs that's what you want. Unfortunately I don't think we can just copy & paste the javax.comm Javadocs into RXTX due to license restrictions. I guess that's the main reason why RXTX is not (yet) Javadoc'd as extensively as it should be. Actually, writing Javadocs from scratch WITHOUT referencing the wording of the Sun Javadocs is not that easy. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of cowwoc > Sent: Freitag, 03. April 2009 06:58 > To: rxtx at qbang.org > Subject: [Rxtx] Missing documentation > > Hi, > > I noticed that RXTX 2.1 drops javax.comm support in favor > of gnu.io. > I have one major problem with this: the gui.io.* > documentation is very > poor. Many classes and methods have no Javadoc at all which > makes them > difficult to use. Please fix this for the final release. > > Thank you, > Gili > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Fri Apr 3 16:54:50 2009 From: netbeans at gatworks.com (U. George) Date: Fri, 03 Apr 2009 18:54:50 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: <49D546F8.20807@gatworks.com> Message-ID: <49D693BA.8060909@gatworks.com> I would have tried 2 or 3 "^\" . If things are stuck, then all will be at same 'java' instruction. If thread is moving, then one of the snapshots would be different. I *think* flushing/draining wont return until the kernel buffers to device have been accepted by device. Stuck/paused device? Bill Johnson wrote: > > > > > When perceived runability is hung, try a ^\ ( control \) on console. > This gets the JVM to dump the stacks of all the java threads. > > > Good idea... A thread dump is below, it looks like only some system > threads are in wait state which is prob From cowwoc at bbs.darktech.org Fri Apr 3 17:45:09 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Fri, 03 Apr 2009 19:45:09 -0400 Subject: [Rxtx] Missing documentation In-Reply-To: <460801A4097E3D4CA04CC64EE648584809C8BD6F@ism-mail03.corp.ad.wrs.com> References: <49D43979.4050702@bbs.darktech.org> <49D5973E.4050400@bbs.darktech.org> <460801A4097E3D4CA04CC64EE648584809C8BD6F@ism-mail03.corp.ad.wrs.com> Message-ID: <49D69F85.3030804@bbs.darktech.org> You could always send Sun a formal email and ask for permission to copy their Javadoc. I doubt they would give you problems. Gili Oberhuber, Martin wrote: > Hello Gili, > > The classes in the gnu.io namespace are designed to work exactly > as their counterparts in the javax.comm namespace. Therefore, > if you just take the javax.comm Javadocs that's what you want. > > Unfortunately I don't think we can just copy & paste the > javax.comm Javadocs into RXTX due to license restrictions. > > I guess that's the main reason why RXTX is not (yet) Javadoc'd > as extensively as it should be. Actually, writing Javadocs > from scratch WITHOUT referencing the wording of the Sun > Javadocs is not that easy. > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] >> On Behalf Of cowwoc >> Sent: Freitag, 03. April 2009 06:58 >> To: rxtx at qbang.org >> Subject: [Rxtx] Missing documentation >> >> Hi, >> >> I noticed that RXTX 2.1 drops javax.comm support in favor >> of gnu.io. >> I have one major problem with this: the gui.io.* >> documentation is very >> poor. Many classes and methods have no Javadoc at all which >> makes them >> difficult to use. Please fix this for the final release. >> >> Thank you, >> Gili >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> From cowwoc at bbs.darktech.org Sat Apr 4 15:13:38 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sat, 04 Apr 2009 17:13:38 -0400 Subject: [Rxtx] Java5 support Message-ID: <49D7CD82.1040904@bbs.darktech.org> Now that you dropped javax.comm support, how about improving the API by replacing Enumation by Iterator, int by enum, and using Generics? It would improve the usability of the API. Gili From cowwoc at bbs.darktech.org Sat Apr 4 16:12:13 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sat, 04 Apr 2009 18:12:13 -0400 Subject: [Rxtx] RXTX Version mismatch in 2.2pre2 Message-ID: <49D7DB3D.5040008@bbs.darktech.org> When using RXTX-2.2pre2 I always get the following message: WARNING: RXTX Version mismatch Jar version = RXTX-2.2pre1 native lib Version = RXTX-2.2pre2 I have double checked that I am using the correct Jar file. Is this a known bug in pre2? Gili From tjarvi at qbang.org Sat Apr 4 16:48:53 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Apr 2009 16:48:53 -0600 (MDT) Subject: [Rxtx] RXTX Version mismatch in 2.2pre2 In-Reply-To: <49D7DB3D.5040008@bbs.darktech.org> References: <49D7DB3D.5040008@bbs.darktech.org> Message-ID: > When using RXTX-2.2pre2 I always get the following message: > > WARNING: RXTX Version mismatch > Jar version = RXTX-2.2pre1 > native lib Version = RXTX-2.2pre2 > Yep. You should still be able to test it. -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Sat Apr 4 16:50:43 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sat, 04 Apr 2009 18:50:43 -0400 Subject: [Rxtx] RXTX Version mismatch in 2.2pre2 In-Reply-To: References: <49D7DB3D.5040008@bbs.darktech.org> Message-ID: <49D7E443.9070404@bbs.darktech.org> In other words this is a known bug that will be fixed in the final version? Gili Trent Jarvi wrote: > > >> When using RXTX-2.2pre2 I always get the following message: >> >> WARNING: RXTX Version mismatch >> Jar version = RXTX-2.2pre1 >> native lib Version = RXTX-2.2pre2 >> > > Yep. > > You should still be able to test it. > > -- > Trent Jarvi > tjarvi at qbang.org From cowwoc at bbs.darktech.org Sat Apr 4 16:57:34 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sat, 04 Apr 2009 18:57:34 -0400 Subject: [Rxtx] IOException: Underlying input stream returned zero bytes Message-ID: <49D7E5DE.2050405@bbs.darktech.org> Hi, There seems to be a bug in RXTX 2.2pre2's handling of InputStream timeouts. If you open a serial port without ever invoking enableReceiveTimeout() then invoking InputStream.read() will always return 0 bytes right away. If you wrap the InputStream and invoke BufferedReader.readline() you will get the following exception: java.io.IOException: Underlying input stream returned zero bytes at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:268) [na:1.6.0_14-ea] at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:306) [na:1.6.0_14-ea] at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:158) [na:1.6.0_14-ea] at java.io.InputStreamReader.read(InputStreamReader.java:167) [na:1.6.0_14-ea] at java.io.BufferedReader.fill(BufferedReader.java:136) [na:1.6.0_14-ea] at java.io.BufferedReader.readLine(BufferedReader.java:299) [na:1.6.0_14-ea] at java.io.BufferedReader.readLine(BufferedReader.java:362) [na:1.6.0_14-ea] [snip] If you enable a timeout, the exception will only occur after the timeout expires. In short, it looks like RXTX is using a default timeout of zero (I am expecting it to block forever). It looks like other people have run into this as well: http://forums.sun.com/thread.jspa?threadID=5165346&start=10&tstart=0 Please confirm whether this is a known bug. Thank you, Gili From tjarvi at qbang.org Sat Apr 4 17:27:19 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Apr 2009 17:27:19 -0600 (MDT) Subject: [Rxtx] IOException: Underlying input stream returned zero bytes In-Reply-To: <49D7E5DE.2050405@bbs.darktech.org> References: <49D7E5DE.2050405@bbs.darktech.org> Message-ID: On Sat, 4 Apr 2009, cowwoc wrote: > Hi, > > There seems to be a bug in RXTX 2.2pre2's handling of InputStream > timeouts. If you open a serial port without ever invoking > enableReceiveTimeout() then invoking InputStream.read() will always > return 0 bytes right away. If you wrap the InputStream and invoke > BufferedReader.readline() you will get the following exception: > > java.io.IOException: Underlying input stream returned zero bytes > at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:268) > [na:1.6.0_14-ea] > at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:306) > [na:1.6.0_14-ea] > at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:158) > [na:1.6.0_14-ea] > at java.io.InputStreamReader.read(InputStreamReader.java:167) > [na:1.6.0_14-ea] > at java.io.BufferedReader.fill(BufferedReader.java:136) > [na:1.6.0_14-ea] > at java.io.BufferedReader.readLine(BufferedReader.java:299) > [na:1.6.0_14-ea] > at java.io.BufferedReader.readLine(BufferedReader.java:362) > [na:1.6.0_14-ea] > [snip] > > If you enable a timeout, the exception will only occur after the > timeout expires. In short, it looks like RXTX is using a default timeout > of zero (I am expecting it to block forever). It looks like other people > have run into this as well: > http://forums.sun.com/thread.jspa?threadID=5165346&start=10&tstart=0 > > Please confirm whether this is a known bug. > Hi Gili I've known about it but was not sure if it was a bug or not. It looks like we can treat it as a bug if nio is throwing an exception. Timeout and Thresholds are well documented in javax.comm but I didn't recall seeing defaults. For that reason, I've encouraged people to set the threshold and timeout to what they expect. Another note about InputStream.read(void): I noticed that I don't use that function at all while looking at code coverage results. Keep your eye out for additional issues. -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Sat Apr 4 19:03:29 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sat, 04 Apr 2009 21:03:29 -0400 Subject: [Rxtx] IOException: Underlying input stream returned zero bytes In-Reply-To: References: <49D7E5DE.2050405@bbs.darktech.org> Message-ID: <49D80361.7020801@bbs.darktech.org> Trent Jarvi wrote: > For that reason, I've encouraged people to set the threshold and timeout > to what they expect. It doesn't help. There doesn't seem to be a way to disable the timeout, even if you invoke disableReceiveTimeout() explicitly. Let me know when you put in a fix and I will test it. Thanks, Gili From cowwoc at bbs.darktech.org Sat Apr 4 23:27:25 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 01:27:25 -0400 Subject: [Rxtx] Crash in termios.c:892 Message-ID: <49D8413D.7040105@bbs.darktech.org> I can reproduce a crash in RXTX 2.2 pre2 100% of the time using my application code, but I can't seem to bring it down to a minimal testcase. Here is what I see: - thread begins running - open com1 - close com1 - open com5 - leave com5 open - thread shuts down - repeat the same process in a new thread - crash occurs when trying to open com1. Crash disappears if I close() com5 in the previous thread. The output window contains the following: # # A fatal error has been detected by the Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x05475cf6, pid=6064, tid=5436 # # JRE version: 6.0_14-b04 # Java VM: Java HotSpot(TM) Client VM (14.0-b13 mixed mode, sharing windows-x86 ) # Problematic frame: # C [rxtxSerial.dll+0x5cf6] # # An error report file with more information is saved as: # C:\Users\Gili\Documents\foobar\source\hs_err_pid6064.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp Error 0x5 at ..\src\termios.c(892): Access is denied. # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # Please let me know if the crash dump is enough to track down this bug. Thank you, Gili -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: hs_err_pid6064.log Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20090405/7133a1ce/attachment-0006.pl From cowwoc at bbs.darktech.org Sun Apr 5 00:24:19 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 02:24:19 -0400 Subject: [Rxtx] SerialPort.getName() is wrong Message-ID: <49D84E93.7050606@bbs.darktech.org> Sorry for all these emails but I keep on running into more issues. Here is what I noticed: - CommPortIdentifier.getPortIdentifier("COM5") returns a CommPortIdentifier where getName() == "COM5" - If, however, you invoke CommPortIdentifier.open() you get back a SerialPort where SerialPort.getName() is "//./COM5" I am expecting the name to remain consistent. "//./COM5" looks like an implementation detail and (as far as I can tell) it can't be used as an argument for any API method so it is somewhat useless. If getName() were to return "COM5" I could at least use it to get back the original CommPortIdentifier or compare against "known names" such as "COMx" or "LPTx". What do you think? Gili From tjarvi at qbang.org Sun Apr 5 10:18:42 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Apr 2009 10:18:42 -0600 (MDT) Subject: [Rxtx] SerialPort.getName() is wrong In-Reply-To: <49D84E93.7050606@bbs.darktech.org> References: <49D84E93.7050606@bbs.darktech.org> Message-ID: On Sun, 5 Apr 2009, cowwoc wrote: > > Sorry for all these emails but I keep on running into more issues. > Here is what I noticed: > > - CommPortIdentifier.getPortIdentifier("COM5") returns a > CommPortIdentifier where getName() == "COM5" > - If, however, you invoke CommPortIdentifier.open() you get back a > SerialPort where SerialPort.getName() is "//./COM5" > > I am expecting the name to remain consistent. "//./COM5" looks like > an implementation detail and (as far as I can tell) it can't be used as > an argument for any API method so it is somewhat useless. If getName() > were to return "COM5" I could at least use it to get back the original > CommPortIdentifier or compare against "known names" such as "COMx" or > "LPTx". What do you think? > Sure. If it itches enough you should be able to fix this in RXTXCommDriver.java. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Apr 5 10:27:58 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Apr 2009 10:27:58 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D8413D.7040105@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> Message-ID: On Sun, 5 Apr 2009, cowwoc wrote: > > I can reproduce a crash in RXTX 2.2 pre2 100% of the time using my > application code, but I can't seem to bring it down to a minimal testcase. > Here is what I see: > > - thread begins running > - open com1 > - close com1 > - open com5 > - leave com5 open > - thread shuts down > - repeat the same process in a new thread > - crash occurs when trying to open com1. Crash disappears if I close() com5 > in the previous thread. > > The output window contains the following: > > # > # A fatal error has been detected by the Java Runtime Environment: > # > # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x05475cf6, pid=6064, > tid=5436 > # > # JRE version: 6.0_14-b04 > # Java VM: Java HotSpot(TM) Client VM (14.0-b13 mixed mode, sharing > windows-x86 ) > # Problematic frame: > # C [rxtxSerial.dll+0x5cf6] > # > # An error report file with more information is saved as: > # C:\Users\Gili\Documents\foobar\source\hs_err_pid6064.log > # > # If you would like to submit a bug report, please visit: > # http://java.sun.com/webapps/bugreport/crash.jsp > Error 0x5 at ..\src\termios.c(892): Access is denied. > > > # The crash happened outside the Java Virtual Machine in native code. > # See problematic frame for where to report the bug. > # > > Please let me know if the crash dump is enough to track down this bug. > Hi Gili, You are responsible for cleaning up the serial ports when using threads. That said, if the thread did shut down, finalize should have been called if you are not passing the object around. See RXTXPort.java. protected void finalize() { if (debug) z.reportln( "RXTXPort:finalize()"); if( fd > 0 ) { if (debug) z.reportln( "RXTXPort:calling close()"); close(); } z.finalize(); } The exception is interesting. This is on Vista? Usually it just gives an open error when another process has the port. -- Trent Jarvi tjarvi at mathworks.com From cowwoc at bbs.darktech.org Sun Apr 5 10:35:55 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 12:35:55 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: References: <49D8413D.7040105@bbs.darktech.org> Message-ID: <49D8DDEB.5010908@bbs.darktech.org> Trent Jarvi wrote: > You are responsible for cleaning up the serial ports when using threads. > That said, if the thread did shut down, finalize should have been called > if you are not passing the object around. See RXTXPort.java. > > protected void finalize() > { > if (debug) > z.reportln( "RXTXPort:finalize()"); > if( fd > 0 ) > { > if (debug) > z.reportln( "RXTXPort:calling close()"); > close(); > } > z.finalize(); > } Two points: 1) One should never rely on finalizers because they may never run. 2) RXTX shouldn't cause the entire JVM to crash if I misuse the API. The native code should recover more gracefully. > The exception is interesting. This is on Vista? Usually it just gives > an open error when another process has the port. Yes, this is on Vista 64-bit. I'd really like to see this bug fixed. Is this code compilable under Visual Studio? If so, I can debug the problem on my end and send you a patch. Thanks, Gili From cowwoc at bbs.darktech.org Sun Apr 5 10:36:20 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 12:36:20 -0400 Subject: [Rxtx] SerialPort.getName() is wrong In-Reply-To: References: <49D84E93.7050606@bbs.darktech.org> Message-ID: <49D8DE04.6030306@bbs.darktech.org> Trent Jarvi wrote: >> I am expecting the name to remain consistent. "//./COM5" looks like >> an implementation detail and (as far as I can tell) it can't be used as >> an argument for any API method so it is somewhat useless. If getName() >> were to return "COM5" I could at least use it to get back the original >> CommPortIdentifier or compare against "known names" such as "COMx" or >> "LPTx". What do you think? >> > > Sure. > > If it itches enough you should be able to fix this in RXTXCommDriver.java. I'm not sure I understand. Are you saying that if I submit a patch you will commit it? Gili From tjarvi at qbang.org Sun Apr 5 10:46:23 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Apr 2009 10:46:23 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D8DDEB.5010908@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> Message-ID: On Sun, 5 Apr 2009, cowwoc wrote: > Trent Jarvi wrote: >> You are responsible for cleaning up the serial ports when using threads. >> That said, if the thread did shut down, finalize should have been called if >> you are not passing the object around. See RXTXPort.java. >> >> protected void finalize() >> { >> if (debug) >> z.reportln( "RXTXPort:finalize()"); >> if( fd > 0 ) >> { >> if (debug) >> z.reportln( "RXTXPort:calling close()"); >> close(); >> } >> z.finalize(); >> } > > Two points: > > 1) One should never rely on finalizers because they may never run. > 2) RXTX shouldn't cause the entire JVM to crash if I misuse the API. The > native code should recover more gracefully. > >> The exception is interesting. This is on Vista? Usually it just gives an >> open error when another process has the port. > > Yes, this is on Vista 64-bit. I'd really like to see this bug fixed. > Is this code compilable under Visual Studio? If so, I can debug the problem > on my end and send you a patch. > It will compile with the msvc cl.exe and nmake. See Makefile.msvc in the top level directory. You will need to adjust the JAVA_HOME variable. Also use the MSVC command prompt for x86_64 so cl and nmake are on your path. All the best, -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Apr 5 10:49:10 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Apr 2009 10:49:10 -0600 (MDT) Subject: [Rxtx] SerialPort.getName() is wrong In-Reply-To: <49D8DE04.6030306@bbs.darktech.org> References: <49D84E93.7050606@bbs.darktech.org> <49D8DE04.6030306@bbs.darktech.org> Message-ID: On Sun, 5 Apr 2009, cowwoc wrote: > Trent Jarvi wrote: >>> I am expecting the name to remain consistent. "//./COM5" looks like >>> an implementation detail and (as far as I can tell) it can't be used as >>> an argument for any API method so it is somewhat useless. If getName() >>> were to return "COM5" I could at least use it to get back the original >>> CommPortIdentifier or compare against "known names" such as "COMx" or >>> "LPTx". What do you think? >>> >> >> Sure. >> >> If it itches enough you should be able to fix this in RXTXCommDriver.java. > > I'm not sure I understand. Are you saying that if I submit a patch > you will commit it? > Hi Gili, Post a patch here and if nobody complains, we will commit it and give you credit. Yep. Other issues like changing the API to use java5 that may break existing apps are likely to run into objections but bug fixes usually get fixed just as you mention. -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Sun Apr 5 10:55:07 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 12:55:07 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> Message-ID: <49D8E26B.2040705@bbs.darktech.org> Trent Jarvi wrote: > It will compile with the msvc cl.exe and nmake. See Makefile.msvc in > the top level directory. You will need to adjust the JAVA_HOME > variable. Also use the MSVC command prompt for x86_64 so cl and nmake > are on your path. This is very odd. The CVS version of the code does not contain this file. Do you keep the latest code somewhere else? Gili From cowwoc at bbs.darktech.org Sun Apr 5 11:01:58 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 13:01:58 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D8E26B.2040705@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> Message-ID: <49D8E406.10708@bbs.darktech.org> cowwoc wrote: > Trent Jarvi wrote: >> It will compile with the msvc cl.exe and nmake. See Makefile.msvc in >> the top level directory. You will need to adjust the JAVA_HOME >> variable. Also use the MSVC command prompt for x86_64 so cl and nmake >> are on your path. > > This is very odd. The CVS version of the code does not contain this > file. Do you keep the latest code somewhere else? Okay I figured it out. CVS head is out of date, the "commapi-0-0-1" revision contains the correct files. Gili From tjarvi at qbang.org Sun Apr 5 11:05:43 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Apr 2009 11:05:43 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D8E26B.2040705@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> Message-ID: CVS HEAD is currently the rxtx 2.0 code. A branch was created long ago for 'experimental' gnu.io work. It just happens that the branch is what everyone uses now. checkout -r commapi-0-0-1 rxtx-devel will get the branch On Sun, 5 Apr 2009, cowwoc wrote: > Trent Jarvi wrote: >> It will compile with the msvc cl.exe and nmake. See Makefile.msvc in the >> top level directory. You will need to adjust the JAVA_HOME variable. Also >> use the MSVC command prompt for x86_64 so cl and nmake are on your path. > > This is very odd. The CVS version of the code does not contain this > file. Do you keep the latest code somewhere else? > > Gili > From cowwoc at bbs.darktech.org Sun Apr 5 14:50:47 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 16:50:47 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> Message-ID: <49D919A7.1070806@bbs.darktech.org> Okay, I tracked down the crash. It's being caused by YACK() using a 80-character buffer. The error message is longer than 80 characters, so _snprintf_s() crashes to avoid a buffer overflow. Please apply the attached patch and add the zipped up Visual Studio project directory. It's not perfect yet but it's a good start. Gili Trent Jarvi wrote: > > CVS HEAD is currently the rxtx 2.0 code. A branch was created long > ago for 'experimental' gnu.io work. It just happens that the branch > is what everyone uses now. > > checkout -r commapi-0-0-1 rxtx-devel > > will get the branch > > On Sun, 5 Apr 2009, cowwoc wrote: > >> Trent Jarvi wrote: >>> It will compile with the msvc cl.exe and nmake. See Makefile.msvc >>> in the top level directory. You will need to adjust the JAVA_HOME >>> variable. Also use the MSVC command prompt for x86_64 so cl and >>> nmake are on your path. >> >> This is very odd. The CVS version of the code does not contain >> this file. Do you keep the latest code somewhere else? >> >> Gili >> -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx-devel.patch Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20090405/d9b82962/attachment-0005.pl -------------- next part -------------- A non-text attachment was scrubbed... Name: Win32.zip Type: application/octet-stream Size: 17764 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20090405/d9b82962/attachment-0007.obj From cowwoc at bbs.darktech.org Sun Apr 5 15:22:01 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 17:22:01 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D919A7.1070806@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> <49D919A7.1070806@bbs.darktech.org> Message-ID: <49D920F9.6080702@bbs.darktech.org> My mistake. The problem in YACK is real, but it isn't the real cause of the crash. The crash is caused by termios.c line 1099: index->prev->next = port; because in my case "index->prev==0". I think the bug is that the code assumes that index will contain a minimum of two entries if we're inserting a previously closed fd. In my case, it only contains one. I'm not sure why you have this code branch (as opposed to appending to the end of index). Please take a look. Thanks, Gili cowwoc wrote: > > Okay, I tracked down the crash. It's being caused by YACK() using a > 80-character buffer. The error message is longer than 80 characters, so > _snprintf_s() crashes to avoid a buffer overflow. > > Please apply the attached patch and add the zipped up Visual Studio > project directory. It's not perfect yet but it's a good start. > > Gili > > Trent Jarvi wrote: >> >> CVS HEAD is currently the rxtx 2.0 code. A branch was created long >> ago for 'experimental' gnu.io work. It just happens that the branch >> is what everyone uses now. >> >> checkout -r commapi-0-0-1 rxtx-devel >> >> will get the branch >> >> On Sun, 5 Apr 2009, cowwoc wrote: >> >>> Trent Jarvi wrote: >>>> It will compile with the msvc cl.exe and nmake. See Makefile.msvc >>>> in the top level directory. You will need to adjust the JAVA_HOME >>>> variable. Also use the MSVC command prompt for x86_64 so cl and >>>> nmake are on your path. >>> >>> This is very odd. The CVS version of the code does not contain >>> this file. Do you keep the latest code somewhere else? >>> >>> Gili >>> From tjarvi at qbang.org Sun Apr 5 16:13:27 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Apr 2009 16:13:27 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D920F9.6080702@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> <49D919A7.1070806@bbs.darktech.org> <49D920F9.6080702@bbs.darktech.org> Message-ID: Hi Gili, Are you using the cvs version? I thought we fixed the linked list issues. A solution was posted to the list. Let me look at work tomorrow to see what I have. On Sun, 5 Apr 2009, cowwoc wrote: > > My mistake. The problem in YACK is real, but it isn't the real cause > of the crash. The crash is caused by termios.c line 1099: > > index->prev->next = port; > > because in my case "index->prev==0". I think the bug is that the code > assumes that index will contain a minimum of two entries if we're inserting a > previously closed fd. In my case, it only contains one. > > I'm not sure why you have this code branch (as opposed to appending > to the end of index). Please take a look. > > Thanks, > Gili > > cowwoc wrote: >> >> Okay, I tracked down the crash. It's being caused by YACK() using a >> 80-character buffer. The error message is longer than 80 characters, so >> _snprintf_s() crashes to avoid a buffer overflow. >> >> Please apply the attached patch and add the zipped up Visual Studio >> project directory. It's not perfect yet but it's a good start. >> >> Gili >> >> Trent Jarvi wrote: >>> >>> CVS HEAD is currently the rxtx 2.0 code. A branch was created long ago >>> for 'experimental' gnu.io work. It just happens that the branch is what >>> everyone uses now. >>> >>> checkout -r commapi-0-0-1 rxtx-devel >>> >>> will get the branch >>> >>> On Sun, 5 Apr 2009, cowwoc wrote: >>> >>>> Trent Jarvi wrote: >>>>> It will compile with the msvc cl.exe and nmake. See Makefile.msvc in >>>>> the top level directory. You will need to adjust the JAVA_HOME >>>>> variable. Also use the MSVC command prompt for x86_64 so cl and nmake >>>>> are on your path. >>>> >>>> This is very odd. The CVS version of the code does not contain this >>>> file. Do you keep the latest code somewhere else? >>>> >>>> Gili >>>> > From ilkka at myller.com Sun Apr 5 23:58:08 2009 From: ilkka at myller.com (Ilkka Myller) Date: Mon, 6 Apr 2009 08:58:08 +0300 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> <49D919A7.1070806@bbs.darktech.org> <49D920F9.6080702@bbs.darktech.org> Message-ID: <19779C97-E0C7-4E3D-B715-F84F50F00CE6@myller.com> Hi all, I've already submitted the patch to fix this issue in february: http://mailman.qbang.org/pipermail/rxtx/2009-February/3989441.html The patch fixes the mentioned doubly linked list handling in termios.c -- I Trent Jarvi kirjoitti 6.4.2009 kello 1.13: > > Hi Gili, > > Are you using the cvs version? I thought we fixed the linked list > issues. > A solution was posted to the list. Let me look at work tomorrow to > see > what I have. > > > > On Sun, 5 Apr 2009, cowwoc wrote: > >> >> My mistake. The problem in YACK is real, but it isn't the real cause >> of the crash. The crash is caused by termios.c line 1099: >> >> index->prev->next = port; >> >> because in my case "index->prev==0". I think the bug is that the >> code >> assumes that index will contain a minimum of two entries if we're >> inserting a >> previously closed fd. In my case, it only contains one. >> >> I'm not sure why you have this code branch (as opposed to appending >> to the end of index). Please take a look. >> >> Thanks, >> Gili >> >> cowwoc wrote: >>> >>> Okay, I tracked down the crash. It's being caused by YACK() >>> using a >>> 80-character buffer. The error message is longer than 80 >>> characters, so >>> _snprintf_s() crashes to avoid a buffer overflow. >>> >>> Please apply the attached patch and add the zipped up Visual >>> Studio >>> project directory. It's not perfect yet but it's a good start. >>> >>> Gili >>> >>> Trent Jarvi wrote: >>>> >>>> CVS HEAD is currently the rxtx 2.0 code. A branch was created >>>> long ago >>>> for 'experimental' gnu.io work. It just happens that the branch >>>> is what >>>> everyone uses now. >>>> >>>> checkout -r commapi-0-0-1 rxtx-devel >>>> >>>> will get the branch >>>> >>>> On Sun, 5 Apr 2009, cowwoc wrote: >>>> >>>>> Trent Jarvi wrote: >>>>>> It will compile with the msvc cl.exe and nmake. See >>>>>> Makefile.msvc in >>>>>> the top level directory. You will need to adjust the JAVA_HOME >>>>>> variable. Also use the MSVC command prompt for x86_64 so cl and >>>>>> nmake >>>>>> are on your path. >>>>> >>>>> This is very odd. The CVS version of the code does not >>>>> contain this >>>>> file. Do you keep the latest code somewhere else? >>>>> >>>>> Gili >>>>> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Steffen.DETTMER at ingenico.com Mon Apr 6 02:53:47 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 6 Apr 2009 10:53:47 +0200 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D919A7.1070806@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> <49D919A7.1070806@bbs.darktech.org> Message-ID: <20090406085347.GM8289@elberon.bln.de.ingenico.com> Hi, just two minor details, first about the errno change, I though #include extern int errno; is correct (POSIX.1) - why this change? second about the log message, I think the maximum length could be limited and the return value of malloc must be checked for != NULL before using. Should it be _snprintf_s( message, 80, _TRUNCATE, "Error 0x%x at %s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); (I know that MS-CRT _snprintf does not guarantee to have a final EOS, but I think _snprintf_s with _TRUNCATE does so?). If it is known that truncation may happen maybe sizeof[message] could be increased; maybe using some %.20s could be used avoiding __FILE__ including big pathes to a message where all the message had been cut-off. To have it portable I think it could be: /* generally: */ #if defined(_MSC_VER) # define snprintf _snprintf #endif snprintf(message, sizeof(message), "Error 0x%x at %.20s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); message[sizeof(message)-1] = '\0'; /* needed for MS CRT snprintf */ (for length and size parameter I think size_t could be an option, but on several platforms, including MS-CRT and older glibc, there is no %z, unfortunately) oki, Steffen * cowwoc wrote on Sun, Apr 05, 2009 at 16:50 -0400: > > Okay, I tracked down the crash. It's being caused by YACK() using a > 80-character buffer. The error message is longer than 80 characters, so > _snprintf_s() crashes to avoid a buffer overflow. > > Please apply the attached patch and add the zipped up Visual Studio > project directory. It's not perfect yet but it's a good start. > > Gili > > Trent Jarvi wrote: > > > >CVS HEAD is currently the rxtx 2.0 code. A branch was created long > >ago for 'experimental' gnu.io work. It just happens that the branch > >is what everyone uses now. > > > >checkout -r commapi-0-0-1 rxtx-devel > > > >will get the branch > > > >On Sun, 5 Apr 2009, cowwoc wrote: > > > >>Trent Jarvi wrote: > >>>It will compile with the msvc cl.exe and nmake. See Makefile.msvc > >>>in the top level directory. You will need to adjust the JAVA_HOME > >>>variable. Also use the MSVC command prompt for x86_64 so cl and > >>>nmake are on your path. > >> > >> This is very odd. The CVS version of the code does not contain > >>this file. Do you keep the latest code somewhere else? > >> > >>Gili > >> > Index: ParallelImp.c > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/ParallelImp.c,v > retrieving revision 1.15.2.36 > diff -u -r1.15.2.36 ParallelImp.c > --- ParallelImp.c 11 Feb 2009 01:04:19 -0000 1.15.2.36 > +++ ParallelImp.c 5 Apr 2009 17:55:23 -0000 > @@ -119,7 +119,7 @@ > # include > #endif > > -extern int errno; > +_CRTIMP extern int * __cdecl _errno(void); > > #include "ParallelImp.h" > > @@ -181,8 +181,6 @@ > > #if defined (WIN32) > > -#define CTL_CODE( DeviceType, Function, Method, Access ) (((DeviceType) << 16) | ((Access) << 14) | ((Function) << 2) | (Method)) > - > #define FILE_DEVICE_PARALLEL_PORT 0x00000016 > #define METHOD_BUFFERED 0 > #define FILE_ANY_ACCESS 0 > @@ -253,7 +251,6 @@ > jobject jobj) > { > int fd = get_java_var( env, jobj,"fd","I" ); > - int status; > #if defined (__linux__) > ioctl(fd, LPGETSTATUS, &status); > #elif defined (WIN32) > Index: SerialImp.c > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v > retrieving revision 1.46.2.203 > diff -u -r1.46.2.203 SerialImp.c > --- SerialImp.c 19 Mar 2009 03:27:48 -0000 1.46.2.203 > +++ SerialImp.c 5 Apr 2009 17:49:48 -0000 > @@ -147,7 +147,7 @@ > #include > #endif /* LIBLOCKDEV */ > > -extern int errno; > +_CRTIMP extern int * __cdecl _errno(void); > > #include "SerialImp.h" > > Index: termios.c > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/termios.c,v > retrieving revision 1.9.2.62 > diff -u -r1.9.2.62 termios.c > --- termios.c 13 Jan 2009 03:08:55 -0000 1.9.2.62 > +++ termios.c 5 Apr 2009 17:54:09 -0000 > @@ -88,7 +88,7 @@ > #define SIGIO 0 > > int my_errno; > -extern int errno; > +_CRTIMP extern int * __cdecl _errno(void); > struct termios_list > { > char filename[80]; > @@ -1350,7 +1350,7 @@ > In that case use EAGAIN. See SerialImp.c:testRead() > ----------------------------------------------------------*/ > > -int serial_read( int fd, void *vb, int size ) > +int serial_read( int fd, void *vb, unsigned int size ) > { > long start, now; > unsigned long nBytes = 0, total = 0, error; > Index: win32termios.h > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/win32termios.h,v > retrieving revision 1.5.2.34 > diff -u -r1.5.2.34 win32termios.h > --- win32termios.h 5 Feb 2009 01:25:05 -0000 1.5.2.34 > +++ win32termios.h 5 Apr 2009 20:29:30 -0000 > @@ -60,6 +60,7 @@ > #include > #include > #include > +#include > #ifdef TRACE > #define ENTER(x) report("entering "x" \n"); > #define LEAVE(x) report("leaving "x" \n"); > @@ -70,8 +71,9 @@ > #if defined(_MSC_VER) > #define YACK() \ > { \ > - char *allocTextBuf, message[80]; \ > - unsigned long nChars; \ > + char *allocTextBuf, *message; \ > + const unsigned short longestNumber = 20; \ > + unsigned long nChars, len; \ > unsigned int errorCode = GetLastError(); \ > nChars = FormatMessage ( \ > FORMAT_MESSAGE_ALLOCATE_BUFFER | \ > @@ -82,8 +84,12 @@ > (LPSTR)&allocTextBuf, \ > 16, \ > NULL ); \ > - _snprintf_s( message, 80, 80, "Error 0x%x at %s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); \ > + len = strlen("Error 0x") + longestNumber + strlen(" at ") + strlen(__FILE__) + longestNumber + \ > + strlen(": ") + ((nChars+1) * sizeof(TCHAR)) + 1; \ > + message = malloc(len); \ > + _snprintf_s( message, len, len - 1, "Error 0x%x at %s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); \ > report_error( message ); \ > + free(message); \ > LocalFree(allocTextBuf); \ > Sleep(1); \ > } > @@ -173,7 +179,7 @@ > int serial_test( char * ); > int serial_open(const char *File, int flags, ... ); > int serial_close(int fd); > -int serial_read(int fd, void *b, int size); > +int serial_read(int fd, void *b, unsigned int size); > int serial_write(int fd, char *Str, int length); > /* > * lcc winsock.h conflicts > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx End of message. ------------------------------------------------------------------->8======= About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From bill7007 at gmail.com Mon Apr 6 16:34:50 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Mon, 6 Apr 2009 18:34:50 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: <49D693BA.8060909@gatworks.com> References: <49D546F8.20807@gatworks.com> <49D693BA.8060909@gatworks.com> Message-ID: Once it hung, three stack dumps minutes apart were exactly the same. I have a noticed that when it hangs, the read appears after flush() enter and before flush leave() that doesn't happen like: RXTXPort:SerialOutputStream:flush() enter RXTXPort:SerialInputStream:read(8192 0 8192) called When it works, flush() enter and leave happen together. It may just be because flush() hangs and read is the only other thread waiting to run at that point. I don't know much about the RXTX design and kernel interaction, just digging through the code some. Is there a design description somewhere? Am hung up on target system compile since UTS_RELEASE seems no longer defined for 2.6.18 up kernels and have not figured a good patch yet. But, that is another issue. Thanks for the good help. On Fri, Apr 3, 2009 at 6:54 PM, U. George wrote: > I would have tried 2 or 3 "^\" . If things are stuck, then all will be at > same 'java' instruction. If thread is moving, then one of the snapshots > would be different. > > I *think* flushing/draining wont return until the kernel buffers to device > have been accepted by device. Stuck/paused device? > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090406/c4b509d8/attachment-0006.html From tjarvi at qbang.org Mon Apr 6 17:45:38 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 6 Apr 2009 17:45:38 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <20090406085347.GM8289@elberon.bln.de.ingenico.com> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> <49D919A7.1070806@bbs.darktech.org> <20090406085347.GM8289@elberon.bln.de.ingenico.com> Message-ID: The error bits in the patch can probably just be dropped out. I don't see what they solve. Your snprintf define appears to work. The following is what I'd like to put in if noone objects. #if defined(_MSC_VER) # define snprintf _snprintf #endif #define YACK() \ { \ char *allocTextBuf, message[80]; \ unsigned long nChars; \ unsigned int errorCode = GetLastError(); \ nChars = FormatMessage ( \ FORMAT_MESSAGE_ALLOCATE_BUFFER | \ FORMAT_MESSAGE_FROM_SYSTEM, \ NULL, \ errorCode, \ MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT), \ (LPSTR)&allocTextBuf, \ 16, \ NULL ); \ snprintf( message, 80, "Error 0x%x at %s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); \ message[sizeof(message)-1] = '\0'; /* needed for MS CRT snprintf */ \ report_error( message ); \ LocalFree(allocTextBuf); \ Sleep(1); \ } On Mon, 6 Apr 2009, Steffen DETTMER wrote: > Hi, > > just two minor details, first about the errno change, I though > > #include > extern int errno; > > is correct (POSIX.1) - why this change? > > second about the log message, I think the maximum length could be > limited and the return value of malloc must be checked for != > NULL before using. > > Should it be > > _snprintf_s( message, 80, _TRUNCATE, "Error 0x%x at %s(%d): %s\n", > errorCode, __FILE__, __LINE__, allocTextBuf); > > (I know that MS-CRT _snprintf does not guarantee to have a final > EOS, but I think _snprintf_s with _TRUNCATE does so?). > > If it is known that truncation may happen maybe sizeof[message] > could be increased; maybe using some %.20s could be used avoiding > __FILE__ including big pathes to a message where all the message > had been cut-off. > > To have it portable I think it could be: > > /* generally: */ > #if defined(_MSC_VER) > # define snprintf _snprintf > #endif > > snprintf(message, sizeof(message), "Error 0x%x at %.20s(%d): %s\n", > errorCode, __FILE__, __LINE__, allocTextBuf); > message[sizeof(message)-1] = '\0'; /* needed for MS CRT snprintf */ > > (for length and size parameter I think size_t could be an option, > but on several platforms, including MS-CRT and older glibc, > there is no %z, unfortunately) > > oki, > > Steffen > > > * cowwoc wrote on Sun, Apr 05, 2009 at 16:50 -0400: >> >> Okay, I tracked down the crash. It's being caused by YACK() using a >> 80-character buffer. The error message is longer than 80 characters, so >> _snprintf_s() crashes to avoid a buffer overflow. >> >> Please apply the attached patch and add the zipped up Visual Studio >> project directory. It's not perfect yet but it's a good start. >> >> Gili >> >> Trent Jarvi wrote: >> > >> >CVS HEAD is currently the rxtx 2.0 code. A branch was created long >> >ago for 'experimental' gnu.io work. It just happens that the branch >> >is what everyone uses now. >> > >> >checkout -r commapi-0-0-1 rxtx-devel >> > >> >will get the branch >> > >> >On Sun, 5 Apr 2009, cowwoc wrote: >> > >> >>Trent Jarvi wrote: >> >>>It will compile with the msvc cl.exe and nmake. See Makefile.msvc >> >>>in the top level directory. You will need to adjust the JAVA_HOME >> >>>variable. Also use the MSVC command prompt for x86_64 so cl and >> >>>nmake are on your path. >> >> >> >> This is very odd. The CVS version of the code does not contain >> >>this file. Do you keep the latest code somewhere else? >> >> >> >>Gili >> >> > >> Index: ParallelImp.c >> =================================================================== >> RCS file: /usr/local/cvsroot/rxtx-devel/src/ParallelImp.c,v >> retrieving revision 1.15.2.36 >> diff -u -r1.15.2.36 ParallelImp.c >> --- ParallelImp.c 11 Feb 2009 01:04:19 -0000 1.15.2.36 >> +++ ParallelImp.c 5 Apr 2009 17:55:23 -0000 >> @@ -119,7 +119,7 @@ >> # include >> #endif >> >> -extern int errno; >> +_CRTIMP extern int * __cdecl _errno(void); >> >> #include "ParallelImp.h" >> >> @@ -181,8 +181,6 @@ >> >> #if defined (WIN32) >> >> -#define CTL_CODE( DeviceType, Function, Method, Access ) (((DeviceType) << 16) | ((Access) << 14) | ((Function) << 2) | (Method)) >> - >> #define FILE_DEVICE_PARALLEL_PORT 0x00000016 >> #define METHOD_BUFFERED 0 >> #define FILE_ANY_ACCESS 0 >> @@ -253,7 +251,6 @@ >> jobject jobj) >> { >> int fd = get_java_var( env, jobj,"fd","I" ); >> - int status; >> #if defined (__linux__) >> ioctl(fd, LPGETSTATUS, &status); >> #elif defined (WIN32) >> Index: SerialImp.c >> =================================================================== >> RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v >> retrieving revision 1.46.2.203 >> diff -u -r1.46.2.203 SerialImp.c >> --- SerialImp.c 19 Mar 2009 03:27:48 -0000 1.46.2.203 >> +++ SerialImp.c 5 Apr 2009 17:49:48 -0000 >> @@ -147,7 +147,7 @@ >> #include >> #endif /* LIBLOCKDEV */ >> >> -extern int errno; >> +_CRTIMP extern int * __cdecl _errno(void); >> >> #include "SerialImp.h" >> >> Index: termios.c >> =================================================================== >> RCS file: /usr/local/cvsroot/rxtx-devel/src/termios.c,v >> retrieving revision 1.9.2.62 >> diff -u -r1.9.2.62 termios.c >> --- termios.c 13 Jan 2009 03:08:55 -0000 1.9.2.62 >> +++ termios.c 5 Apr 2009 17:54:09 -0000 >> @@ -88,7 +88,7 @@ >> #define SIGIO 0 >> >> int my_errno; >> -extern int errno; >> +_CRTIMP extern int * __cdecl _errno(void); >> struct termios_list >> { >> char filename[80]; >> @@ -1350,7 +1350,7 @@ >> In that case use EAGAIN. See SerialImp.c:testRead() >> ----------------------------------------------------------*/ >> >> -int serial_read( int fd, void *vb, int size ) >> +int serial_read( int fd, void *vb, unsigned int size ) >> { >> long start, now; >> unsigned long nBytes = 0, total = 0, error; >> Index: win32termios.h >> =================================================================== >> RCS file: /usr/local/cvsroot/rxtx-devel/src/win32termios.h,v >> retrieving revision 1.5.2.34 >> diff -u -r1.5.2.34 win32termios.h >> --- win32termios.h 5 Feb 2009 01:25:05 -0000 1.5.2.34 >> +++ win32termios.h 5 Apr 2009 20:29:30 -0000 >> @@ -60,6 +60,7 @@ >> #include >> #include >> #include >> +#include >> #ifdef TRACE >> #define ENTER(x) report("entering "x" \n"); >> #define LEAVE(x) report("leaving "x" \n"); >> @@ -70,8 +71,9 @@ >> #if defined(_MSC_VER) >> #define YACK() \ >> { \ >> - char *allocTextBuf, message[80]; \ >> - unsigned long nChars; \ >> + char *allocTextBuf, *message; \ >> + const unsigned short longestNumber = 20; \ >> + unsigned long nChars, len; \ >> unsigned int errorCode = GetLastError(); \ >> nChars = FormatMessage ( \ >> FORMAT_MESSAGE_ALLOCATE_BUFFER | \ >> @@ -82,8 +84,12 @@ >> (LPSTR)&allocTextBuf, \ >> 16, \ >> NULL ); \ >> - _snprintf_s( message, 80, 80, "Error 0x%x at %s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); \ >> + len = strlen("Error 0x") + longestNumber + strlen(" at ") + strlen(__FILE__) + longestNumber + \ >> + strlen(": ") + ((nChars+1) * sizeof(TCHAR)) + 1; \ >> + message = malloc(len); \ >> + _snprintf_s( message, len, len - 1, "Error 0x%x at %s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); \ >> report_error( message ); \ >> + free(message); \ >> LocalFree(allocTextBuf); \ >> Sleep(1); \ >> } >> @@ -173,7 +179,7 @@ >> int serial_test( char * ); >> int serial_open(const char *File, int flags, ... ); >> int serial_close(int fd); >> -int serial_read(int fd, void *b, int size); >> +int serial_read(int fd, void *b, unsigned int size); >> int serial_write(int fd, char *Str, int length); >> /* >> * lcc winsock.h conflicts >> > > >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > > > > > > > > > > > > End of message. > ------------------------------------------------------------------->8======= > > > About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. > This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > P Please consider the environment before printing this e-mail > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Apr 6 18:11:28 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 6 Apr 2009 18:11:28 -0600 (MDT) Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: <49D546F8.20807@gatworks.com> <49D693BA.8060909@gatworks.com> Message-ID: UTS_RELEASE is defined in now. The check really should be removed from RXTX. It was a defensive check for wilder times when GNU glibc did not have defines the kernel headers had so rxtx would include the kernel headers instead. :/ If you don't have linux/version.h, it is generated when you configure the kernel. make oldconfig used to do the trick. It may make sense to work with the prerelease or CVS code. RXTX just assumes that flush, read and anything else the kernel exposes may be called at anytime from any thread. There isn't a design for the kernel interaction. There are higher level constraints put in Java to prevent some things happening at the same time with 'synchronized.' RXTXPort.java has all of those. When the port is opened, a native event thread is started which uses select to know if an event has happened. BSD like systems have a native thread that fires off on write which tries to flush() to determine when the output buffer is empty asynchronously. The rest is not marshaled in any fashion at the native level. T I think there is a lower level deadlock being triggered in flush as well. I don't think it should be possible if everything was right underneath us. You may want to examine the java code closer to make sure it isnt possible the lock is there. On Mon, 6 Apr 2009, Bill Johnson wrote: > Once it hung, three stack dumps minutes apart were exactly the same. > I have a noticed that when it hangs, the read appears after flush() enter and > before flush leave() that doesn't happen like: > RXTXPort:SerialOutputStream:flush() enter > RXTXPort:SerialInputStream:read(8192 0 8192) called > > When it works, flush() enter and leave happen together. It may just be because > flush() hangs and read is the only other thread waiting to run at that point. > I don't know much about the RXTX design and kernel interaction, just digging > through the code some. Is there a design description somewhere? > > Am hung up on target system compile since UTS_RELEASE seems no longer defined for > 2.6.18 up kernels and have not figured a good patch yet. But, that is another > issue. > > Thanks for the good help. > > > On Fri, Apr 3, 2009 at 6:54 PM, U. George wrote: > I would have tried 2 or 3 "^\" . If things are stuck, then all will be > at same 'java' instruction. If thread is moving, then one of the > snapshots would be different. > > I *think* flushing/draining wont return until the kernel buffers to > device have been accepted by device. Stuck/paused device? > > > > > From tjarvi at qbang.org Mon Apr 6 18:28:50 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 6 Apr 2009 18:28:50 -0600 (MDT) Subject: [Rxtx] CVS updates. Pre3 is comming. Message-ID: I need to go through the bugzilla reports prior to the pre3 release. I think this should be close if you want to check it out from CVS. added: YACK() debug overflow fix for windows Steffen DETTMER (and many others) multiport fix for windows. Ilkka Myller http://mailman.qbang.org/pipermail/rxtx/2009-February/3989441.html I think this code is current. If I missed something, yell. CVS Info: export/setenv CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login # passwd mousy cvs checkout -r commapi-0-0-1 rxtx-devel -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Apr 6 22:32:07 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 6 Apr 2009 22:32:07 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D919A7.1070806@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> <49D919A7.1070806@bbs.darktech.org> Message-ID: Ah. I'll put this in CVS tomorrow. I did sync up the code with my work sandbox today. I just forgot to pull and add this. On Sun, 5 Apr 2009, cowwoc wrote: > > Okay, I tracked down the crash. It's being caused by YACK() using a > 80-character buffer. The error message is longer than 80 characters, so > _snprintf_s() crashes to avoid a buffer overflow. > > Please apply the attached patch and add the zipped up Visual Studio > project directory. It's not perfect yet but it's a good start. > > Gili > > Trent Jarvi wrote: >> >> CVS HEAD is currently the rxtx 2.0 code. A branch was created long ago for >> 'experimental' gnu.io work. It just happens that the branch is what >> everyone uses now. >> >> checkout -r commapi-0-0-1 rxtx-devel >> >> will get the branch >> >> On Sun, 5 Apr 2009, cowwoc wrote: >> >>> Trent Jarvi wrote: >>>> It will compile with the msvc cl.exe and nmake. See Makefile.msvc in the >>>> top level directory. You will need to adjust the JAVA_HOME variable. >>>> Also use the MSVC command prompt for x86_64 so cl and nmake are on your >>>> path. >>> >>> This is very odd. The CVS version of the code does not contain this >>> file. Do you keep the latest code somewhere else? >>> >>> Gili >>> > From cowwoc at bbs.darktech.org Tue Apr 7 06:07:46 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Tue, 07 Apr 2009 08:07:46 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: References: Message-ID: <49DB4212.40807@bbs.darktech.org> > just two minor details, first about the errno change, I though > > #include > extern int errno; > > is correct (POSIX.1) - why this change? If you compile this under Visual Studio 2008 you will get warnings that the errno type being imported is different from the type being exported. The definition I pasted is the one being exported. Perhaps we should use #ifdef WIN32 for this? Gili From bill7007 at gmail.com Tue Apr 7 17:58:54 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Tue, 7 Apr 2009 19:58:54 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: <49D546F8.20807@gatworks.com> <49D693BA.8060909@gatworks.com> Message-ID: I have traced the hang down to a call to tcdrain(fd) in SerialImp.c:drain() running and rebuilt under Netbeans on the target machine with debug messages on. That puts it into the system code, so I'm not sure how to proceed. I guess I could debug into the kernel source but I've not done that. I saw some discussion about an IOCTL that sets/adjusts a timeout on tcdrain() but that may have been for BSD. Maybe there is some new setup requirement or bug introduced with this 2.6.18 kernel or a hardware difference. Below is a message listing with some of the repeated parts removed. Maybe you can see something noteworthy? JNI_OnLoad called. WARNING: RXTX Version mismatch Jar version = RXTX-2.2pre2 native lib Version = RXTX-2.2pre3 entering RXTXCommDriver:getDeviceDirectory entering RXTXPort:testRead fhs_lock: creating lockfile: 29704 fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXPort:testRead RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB2 fhs_lock: creating lockfile: 29704 fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXPort:testRead RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB1 fhs_lock: creating lockfile: 29704 fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXPort:testRead RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB0 fhs_lock: creating lockfile: 29704 fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXPort:testRead fhs_lock: creating lockfile: 29704 ... REPEATS fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXPort:testRead fhs_lock: creating lockfile: 29704 fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXCommDriver:getDeviceDirectory entering RXTXPort:testRead fhs_lock: creating lockfile: 29704 ...REPEATS fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXPort:testRead fhs_lock: creating lockfile: 29704 fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXPort:Initialize RXTX WARNING: This library was compiled to run with OS release 2.6.18 and you are currently running OS release 2.6.18-92.1.6.el5. In some cases this can be a problem. Try recompiling RXTX if you notice strange behavior. If you just compiled RXTX make sure /usr/include/linux is a symbolic link to the include files that came with the kernel source and not an older copy. press enter to continue leaving RXTXPort:Initialize entering RXTXPort:open fhs_lock: creating lockfile: 29704 open: locking worked for /dev/ttyUSB2 open: fd returned is 9 leaving RXTXPort:open entering eventLoop has_line_status_register_acess: Port does not support TIOCSERGETLSR driver_has_tiocgicount: Port does not support TIOCGICOUNT events init_threads: get eis init_threads: set eis init_threads: stop leaving RXTXPort:translate_speed entering RXTXPort:nativeSetSerialPortParams entering translate_date_bits entering translate_stop_bits leaving RXTXPort:translate_stop_bits entering translate_parity leaving translate_parity entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 ...REPEATS entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 leaving RXTXPort:nativeSetSerialPortParams entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 ...REPEATS entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 entering writeArray entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 writeArray() leaving RXTXPort:writeArray entering SerialImp.c:drain() nativeDrain: trying tcdrain RXTXPort:drain() returns: 0 leaving RXTXPort:drain() entering writeArray writeArray() leaving RXTXPort:writeArray entering SerialImp.c:drain() nativeDrain: trying tcdrain entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 Tue Apr 07 18:51:49 EDT 2009:TSerial[22]:Using Port:/dev/ttyUSB2 Tue Apr 07 18:51:49 EDT 2009:TSerial[22].Transmit:TN Tue Apr 07 18:51:49 EDT 2009:TSerial[22].Transmit:RV entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 ...REPEATS FOREVER? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090407/f26e5752/attachment-0005.html From tjarvi at qbang.org Tue Apr 7 18:31:23 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 7 Apr 2009 18:31:23 -0600 (MDT) Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: <49D546F8.20807@gatworks.com> <49D693BA.8060909@gatworks.com> Message-ID: On Tue, 7 Apr 2009, Bill Johnson wrote: > I have traced the hang down to a call to tcdrain(fd) in SerialImp.c:drain() > running and rebuilt under Netbeans on the target machine with debug messages > on. That puts it into the system code, so I'm not sure how to proceed. I > guess I could debug into the kernel source but I've not done that. I saw > some discussion about an IOCTL that sets/adjusts a timeout on tcdrain() but > that may have been for BSD. Maybe there is some new setup requirement or bug > introduced with this 2.6.18 kernel or a hardware difference. > Below is a message listing with some of the repeated parts removed. Maybe > you can see something noteworthy? > > JNI_OnLoad called. > WARNING:? RXTX Version mismatch > ??????? Jar version = RXTX-2.2pre2 > ??????? native lib Version = RXTX-2.2pre3 > entering RXTXCommDriver:getDeviceDirectory > entering RXTXPort:testRead > fhs_lock: creating lockfile:????? 29704 > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXPort:testRead > RXTX Warning:? Removing stale lock file. /var/lock/LCK..ttyUSB2 > fhs_lock: creating lockfile:????? 29704 > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXPort:testRead > RXTX Warning:? Removing stale lock file. /var/lock/LCK..ttyUSB1 > fhs_lock: creating lockfile:????? 29704 > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXPort:testRead > RXTX Warning:? Removing stale lock file. /var/lock/LCK..ttyUSB0 > fhs_lock: creating lockfile:????? 29704 > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXPort:testRead > fhs_lock: creating lockfile:????? 29704 > > ... REPEATS > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXPort:testRead > fhs_lock: creating lockfile:????? 29704 > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXCommDriver:getDeviceDirectory > entering RXTXPort:testRead > fhs_lock: creating lockfile:????? 29704 > > ...REPEATS > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXPort:testRead > fhs_lock: creating lockfile:????? 29704 > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXPort:Initialize > > > > RXTX WARNING:? This library was compiled to run with OS release 2.6.18 and > you are currently running OS release 2.6.18-92.1.6.el5.? In some cases this > can be a problem.? Try recompiling RXTX if you notice strange behavior.? If > you just compiled RXTX make sure /usr/include/linux is a symbolic link to > the include files that came with the kernel source and not an older copy. > > > press enter to continue > > leaving RXTXPort:Initialize > entering RXTXPort:open > fhs_lock: creating lockfile:????? 29704 > > open: locking worked for /dev/ttyUSB2 > open: fd returned is 9 > leaving RXTXPort:open > entering eventLoop > ? > has_line_status_register_acess: Port does not support TIOCSERGETLSR > ?driver_has_tiocgicount:? Port does not support TIOCGICOUNT events > init_threads: get eis > init_threads: set eis > init_threads:? stop > leaving RXTXPort:translate_speed > entering RXTXPort:nativeSetSerialPortParams > entering translate_date_bits > entering translate_stop_bits > leaving RXTXPort:translate_stop_bits > entering translate_parity > leaving translate_parity > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > ...REPEATS > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > leaving RXTXPort:nativeSetSerialPortParams > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > ...REPEATS > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > entering writeArray > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > writeArray() > leaving RXTXPort:writeArray > entering SerialImp.c:drain() > nativeDrain: trying tcdrain > RXTXPort:drain() returns: 0 > leaving RXTXPort:drain() > entering writeArray > writeArray() > leaving RXTXPort:writeArray > entering SerialImp.c:drain() > nativeDrain: trying tcdrain > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > Tue Apr 07 18:51:49 EDT 2009:TSerial[22]:Using Port:/dev/ttyUSB2 > Tue Apr 07 18:51:49 EDT 2009:TSerial[22].Transmit:TN > > Tue Apr 07 18:51:49 EDT 2009:TSerial[22].Transmit:RV > > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > ...REPEATS FOREVER? > > > Hi Bill ugh. The tiocmget... is the eventLoop checking for events. It sits with select() but has a timeout value to keep it spinning at a trivial rate. tcdrain() is the suspect. I don't see anything in the code that looks like a problem. If flow control is not enabled, I don't see a reason for it not to return. Given that this is USB, perhaps a message from the device got lost. Onboard UARTs would have a status register change when output buffer is empty. USB needs to communicate the event as an HID device which may be the source of the error. Dropping back to onboard UARTs eliminates that portion of the mix. What vendor/chipset is the USB dongle? I understand code has been pushed upon the linux serial devices for new for things like acpi. There very well could be a bug introduced. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Apr 7 18:38:22 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 7 Apr 2009 18:38:22 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49DB4212.40807@bbs.darktech.org> References: <49DB4212.40807@bbs.darktech.org> Message-ID: On Tue, 7 Apr 2009, cowwoc wrote: >> just two minor details, first about the errno change, I though >> >> #include >> extern int errno; >> >> is correct (POSIX.1) - why this change? > > If you compile this under Visual Studio 2008 you will get warnings that > the errno type being imported is different from the type being exported. > The definition I pasted is the one being exported. Perhaps we should use > #ifdef WIN32 for this? > Hi Gili, Perhaps a workaround for _MSVC is in order. GNU compilers for windows won't complain. If it's a question of MSVC or POSIX being right, the library favors the standard as a stated goal. I'm not sure what MSVC is using errno for but it should not be using it except with POSIX extensions. Perhaps #undef is enough to get rid of the warning and (maybe) has no ill consequences. Newer windows have POSIX extensions that may show how Microsoft solved the problem. It can probably fester. -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Tue Apr 7 19:54:06 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Tue, 07 Apr 2009 21:54:06 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: References: <49DB4212.40807@bbs.darktech.org> Message-ID: <49DC03BE.5010203@bbs.darktech.org> Trent Jarvi wrote: > I'm not sure what MSVC is using errno for but it should not be using it > except with POSIX extensions. Perhaps #undef is enough to get rid of > the warning and (maybe) has no ill consequences. Newer windows have > POSIX extensions that may show how Microsoft solved the problem. > > It can probably fester. What does "newer windows" refer to in this case? I was compiling using Visual Studio 2008 sp1 under Windows Vista. Both are cutting edge technologies as far as official releases go. I think you're best suited to judge whether this warning is a big deal or not so I think you should see it for yourself. Please try firing up Visual Studio 2008 (express?) against the project I sent you. Gili From Steffen.DETTMER at ingenico.com Wed Apr 8 05:50:42 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 8 Apr 2009 13:50:42 +0200 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49DC03BE.5010203@bbs.darktech.org> References: <49DB4212.40807@bbs.darktech.org> <49DC03BE.5010203@bbs.darktech.org> Message-ID: <20090408115042.GC5090@elberon.bln.de.ingenico.com> * cowwoc wrote on Tue, Apr 07, 2009 at 21:54 -0400: > Trent Jarvi wrote: > > I'm not sure what MSVC is using errno for but it should not be using it > > except with POSIX extensions. Perhaps #undef is enough to get rid of > > the warning and (maybe) has no ill consequences. Newer windows have > > POSIX extensions that may show how Microsoft solved the problem. I think here best is simply to omit this old^Wclassic `extern int errno;' line completely. I think standards just say something like `implementations may support the declaration extern int errno;'. About POSIX extensions I think in general it should be considered that althrough many things are available, even with MS Visual C++, the Microsoft tools lead developers to write non-portable code (and personally I think this is intentional). For example, they call the official ISO-C function `strerror' deprecated (!) and twaddle about some security enhancements (without even beeing specific). Someone could, because of this, lead to use the MS specific, unportable `strerror_s' instead. Even better, at _strerror_s they tell, for `ANSI compatiblity someone should use strerror_s'. Of course a program using [_]strerror_s won't be ANSI-C compliant. Do they mean strerror_r? _strerror_s has the same parameters - but of course in different order - to make porting a pain... SCNR. > What does "newer windows" refer to in this case? I was compiling using > Visual Studio 2008 sp1 under Windows Vista. Both are cutting edge > technologies as far as official releases go. `cutting edge technologies' yeah post-standard, portability-cutting technologies smoothing the way to MS world domination; own post-ANSI-C programming languages help (maybe to increase the share holder value)... SCNR. > I think you're best suited to judge whether this warning is a big deal > or not so I think you should see it for yourself. Please try firing up > Visual Studio 2008 (express?) against the project I sent you. yeah, getting the CL.EXE of 2008 running in a normal command line environment (without its special `C++ Shell') is a bit tricky - but possible. ;) oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From tjarvi at qbang.org Wed Apr 8 14:29:54 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 8 Apr 2009 14:29:54 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49DC03BE.5010203@bbs.darktech.org> References: <49DB4212.40807@bbs.darktech.org> <49DC03BE.5010203@bbs.darktech.org> Message-ID: The support has been around for a long time to. I don't know the details but the support appears to be tied to the OS. http://en.wikipedia.org/wiki/POSIX#POSIX_for_Windows On Tue, 7 Apr 2009, cowwoc wrote: > Trent Jarvi wrote: >> I'm not sure what MSVC is using errno for but it should not be using it >> except with POSIX extensions. Perhaps #undef is enough to get rid of the >> warning and (maybe) has no ill consequences. Newer windows have POSIX >> extensions that may show how Microsoft solved the problem. >> >> It can probably fester. > > What does "newer windows" refer to in this case? I was compiling > using Visual Studio 2008 sp1 under Windows Vista. Both are cutting edge > technologies as far as official releases go. > > I think you're best suited to judge whether this warning is a big > deal or not so I think you should see it for yourself. Please try firing up > Visual Studio 2008 (express?) against the project I sent you. > > Gili > From bill7007 at gmail.com Wed Apr 8 15:59:08 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Wed, 8 Apr 2009 17:59:08 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: <49D546F8.20807@gatworks.com> <49D693BA.8060909@gatworks.com> Message-ID: Hi Trent, I think I have hit on a work around but don't know why it works. The USB serial adapter is a "CableMAX" based on Prolific's PL2303. Backing out to the big picture, the application is old and has been very reliable until put on a new cpu and kernel. It only hangs sometimes say 25% and always at the same place, at tcdrain() on the flush() after the second write after startup. If it made it past this stage, all transmit and receive seemed reliable so it was like a startup timing issue. Since learning to debug kernel code is beyond my immediate priority, I took a shot at moving code around, adding delays, and such. I have found it good practice to do a flush after every write on streams like: outputStream.write(data.getBytes()); outputStream.flush(); If I remove the flush() after each write, the problem appears to go away! I don't think the flush is needed for a SerialOutputStream for this application anyway. Thanks for all the help, +BillJ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090408/35d96a9d/attachment-0003.html From bill7007 at gmail.com Thu Apr 9 09:20:11 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Thu, 9 Apr 2009 11:20:11 -0400 Subject: [Rxtx] Baud rate fixes in 2.2pre2 breaks 38400 on some Linux devices Message-ID: Hello, An application that worked at 38400 on a USB serial adapter (PL2303) using 2.1-7-r2 on Linux EL4 (and EL5) now fails using 2.2pre2. serialPort.setSerialPortParams(38400,SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); throws an unsupportedCommOperationException This problem matched a description of Bug 113and I posted a proposed patch there, but I don't understand the whole custom baud rate patch so it may need some thought. An older patch, [Rxtx] [Patch]: Baud Rate fixes try 1, testing encouraged., fixed some custom baud rates but apparently broke 38400 on some Linux device. Other baud rates seem to work OK. And, 38400 tested OK on local non-USB ports. My proposed patch probably breaks the custom baud rate patch since it was keyed on 38400 as a special case for Linux and my fix was to back out part of that patch, specifically: #if defined(TIOCGSERIAL) if ( cspeed == B38400 ) cspeed = 38400; #endif /* TIOCGSERIAL */ +BillJ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090409/5636af64/attachment-0002.html From cowwoc at bbs.darktech.org Fri Apr 10 08:38:49 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Fri, 10 Apr 2009 10:38:49 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: References: <49DB4212.40807@bbs.darktech.org> <49DC03BE.5010203@bbs.darktech.org> Message-ID: <49DF59F9.2050408@bbs.darktech.org> Doesn't Wikipedia list as an optional sub-system? Gili Trent Jarvi wrote: > > The support has been around for a long time to. I don't know the > details but the support appears to be tied to the OS. > > http://en.wikipedia.org/wiki/POSIX#POSIX_for_Windows > > On Tue, 7 Apr 2009, cowwoc wrote: > >> Trent Jarvi wrote: >>> I'm not sure what MSVC is using errno for but it should not be using >>> it except with POSIX extensions. Perhaps #undef is enough to get >>> rid of the warning and (maybe) has no ill consequences. Newer >>> windows have POSIX extensions that may show how Microsoft solved the >>> problem. >>> >>> It can probably fester. >> >> What does "newer windows" refer to in this case? I was compiling >> using Visual Studio 2008 sp1 under Windows Vista. Both are cutting >> edge technologies as far as official releases go. >> >> I think you're best suited to judge whether this warning is a big >> deal or not so I think you should see it for yourself. Please try >> firing up Visual Studio 2008 (express?) against the project I sent you. >> >> Gili >> From cowwoc at bbs.darktech.org Wed Apr 1 22:05:13 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Thu, 02 Apr 2009 00:05:13 -0400 Subject: [Rxtx] Windows 64-bit support? Message-ID: <49D43979.4050702@bbs.darktech.org> Hi, I'd like to run RXTX under the Windows 64-bit JVM. Are there plans to release an official 64-bit version anytime soon? Gili From bill7007 at gmail.com Thu Apr 2 16:01:17 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Thu, 2 Apr 2009 18:01:17 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel Message-ID: Hi, I have an rxtx serial application that used to work reliably until I had to move it to newer hardware and kernel. Now, the application sometimes hangs near first port use. When it does hang, it can be released by starting a second copy of the application which is locked out of the ports but does release the first process. Upgraded from rxtx-2.1-7-r2 to rxtx-2.2pre2 but still hangs. Tried to rebuild on the target machine and ran into the 'UTS_RELEASE' undeclared problem so holding on that approach. Recompiled OK on a 2.6.9-42.0.3.ELsmp system. Debug messages were turned on using: "./configure --enable-DEBUG" and modified RXTXPort.java with: "debug = true;" "z = new Zystem(Zystem.PRINT_MODE);" Below is capture of the application with debugging enabled. It show the application hang point, and the second application's printout at the release point. (pre3 is the locally modified version of pre2) Any suggestions on how to pin this down further? Thanks, +BillJ $ java -version java version "1.5.0_06" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05) Java HotSpot(TM) Client VM (build 1.5.0_06-b05, mixed mode, sharing) $ uname -a Linux qms4 2.6.18-92.1.6.el5 #1 SMP Wed Jun 25 13:49:24 EDT 2008 i686 i686 i386 GNU/Linux ***CAPTURE: [qms at qms4 ~]$ ./qms/ScriptFiles/startup.sh Thu Apr 02 13:35:45 EDT 2009:Setting Log File to:/home/qms/qms/QMS.log Thu Apr 02 13:35:45 EDT 2009:TSettings.HandleIni:ReUsing Ini file:/home/qms/qms/qms.properties WARNING: RXTX Version mismatch Jar version = RXTX-2.2pre2 native lib Version = RXTX-2.2pre3 fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB2 fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB1 fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB0 fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile RXTXPort {} RXTX WARNING: This library was compiled to run with OS release 2.4.20 and you are currently running OS release 2.6.18-92.1.6.el5. In some cases this can be a problem. Try recompiling RXTX if you notice strange behavior. If you just compiled RXTX make sure /usr/include/linux is a symbolic link to the include files that came with the kernel source and not an older copy. press enter to continue RXTXPort:RXTXPort(/dev/ttyUSB2) called fhs_lock: creating lockfile: 10127 open: locking worked for /dev/ttyUSB2 open: fd returned is 8 RXTXPort:MontitorThread:MonitorThread() RXTXPort:MontitorThread:run() has_line_status_register_acess: Port does not support TIOCSERGETLSR init_threads: get eis init_threads: set eis init_threads: stop RXTXPort:RXTXPort(/dev/ttyUSB2) returns with fd = 8 RXTXPort:setSerialPortParams(38400 8 1 0) called RXTXPort:setSerialPortParams(38400 8 1 0) returning RXTXPort:getInputStream() called and returning Thu Apr 02 13:36:02 EDT 2009:TSerial[22]:Using Port:/dev/ttyUSB2 RXTXPort:getOutputStream() called and returning Thu Apr 02 13:36:02 EDT 2009:TSerial[22].Transmit:TN Entering RXTXPort:SerialOutputStream:write(4) writeArray() Leaving RXTXPort:SerialOutputStream:write(4) RXTXPort:SerialOutputStream:flush() enter RXTXPort:SerialOutputStream:flush() leave Thu Apr 02 13:36:02 EDT 2009:TSerial[22].Transmit:RV Entering RXTXPort:SerialOutputStream:write(4) writeArray() Leaving RXTXPort:SerialOutputStream:write(4) RXTXPort:SerialOutputStream:flush() enter RXTXPort:SerialInputStream:read(8192 0 8192) called ***FIRST PROCESS HANGS HERE ***THEN PROCEEDS AFTER SECOND PROCESS STARTS RXTXPort:SerialOutputStream:flush() leave Thu Apr 02 13:41:29 EDT 2009:TSerial[22].Transmit:IH9 Entering RXTXPort:SerialOutputStream:write(5) writeArray() Leaving RXTXPort:SerialOutputStream:write(5) RXTXPort:SerialOutputStream:flush() enter RXTXPort:SerialOutputStream:flush() leave Thu Apr 02 13:41:29 EDT 2009:TSerial[22].Transmit:IL11 ***END CAPTURE ***CAPTURE SECOND PROCESS FAILS OPEN [qms at qms4 ~]$ ./qms/ScriptFiles/startup.sh Thu Apr 02 13:41:27 EDT 2009:Setting Log File to:/home/qms/qms/QMS.log Thu Apr 02 13:41:27 EDT 2009:TSettings.HandleIni:ReUsing Ini file:/home/qms/qms/qms.properties WARNING: RXTX Version mismatch Jar version = RXTX-2.2pre2 native lib Version = RXTX-2.2pre3 fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB2: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB1: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB0: File exists fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB2: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB1: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB0: File exists fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile Thu Apr 02 13:41:30 EDT 2009:TIOBoard: java.io.IOException: java.io.IOException: TSerial[22]: Open Failed ***END CAPTURE -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090402/c66f8d70/attachment-0011.html From netbeans at gatworks.com Thu Apr 2 17:15:04 2009 From: netbeans at gatworks.com (U. George) Date: Thu, 02 Apr 2009 19:15:04 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: Message-ID: <49D546F8.20807@gatworks.com> > "z = new Zystem(Zystem.PRINT_MODE);" > Below is capture of the application with debugging enabled. It show > the application hang point, and the second application's printout at the > release point. (pre3 is the locally modified version of pre2) > Any suggestions on how to pin this down further? > Thanks, > +BillJ When perceived runability is hung, try a ^\ ( control \) on console. This gets the JVM to dump the stacks of all the java threads. If you know the thread that is stuck, then u can see what java statement its stuck at. From tjarvi at qbang.org Thu Apr 2 19:25:17 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 2 Apr 2009 19:25:17 -0600 (MDT) Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: <49D546F8.20807@gatworks.com> References: <49D546F8.20807@gatworks.com> Message-ID: On Thu, 2 Apr 2009, U. George wrote: >> "z = new Zystem(Zystem.PRINT_MODE);" >> Below is capture of the application with debugging enabled. It show >> the application hang point, and the second application's printout at the >> release point. (pre3 is the locally modified version of pre2) >> Any suggestions on how to pin this down further? >> Thanks, >> +BillJ > > When perceived runability is hung, try a ^\ ( control \) on console. > This gets the JVM to dump the stacks of all the java threads. > If you know the thread that is stuck, then u can see what java statement > its stuck at. I've also noticed some linux systems hanging with open/read/write and saw kacpid storms. I need to look at it more but did observe kacpid consuming a core and not returning to a normal state for a significant period of time. It was easy to observe from top sorted by CPU usage. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Apr 2 19:26:18 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 2 Apr 2009 19:26:18 -0600 (MDT) Subject: [Rxtx] Windows 64-bit support? In-Reply-To: <49D43979.4050702@bbs.darktech.org> References: <49D43979.4050702@bbs.darktech.org> Message-ID: On Thu, 2 Apr 2009, cowwoc wrote: > Hi, > > I'd like to run RXTX under the Windows 64-bit JVM. Are there plans > to release an official 64-bit version anytime soon? > It is in the prerelease and will be in the final release. I'm pushing it through as fast as I can in my free time. -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Thu Apr 2 22:57:34 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Fri, 03 Apr 2009 00:57:34 -0400 Subject: [Rxtx] Missing documentation In-Reply-To: References: <49D43979.4050702@bbs.darktech.org> Message-ID: <49D5973E.4050400@bbs.darktech.org> Hi, I noticed that RXTX 2.1 drops javax.comm support in favor of gnu.io. I have one major problem with this: the gui.io.* documentation is very poor. Many classes and methods have no Javadoc at all which makes them difficult to use. Please fix this for the final release. Thank you, Gili From alex.sas at freemail.hu Fri Apr 3 01:36:54 2009 From: alex.sas at freemail.hu (Sas Alex) Date: Fri, 3 Apr 2009 09:36:54 +0200 (CEST) Subject: [Rxtx] Serial port false reads Message-ID: Hi all, On Windows XP, using rxtx-2.1-7-r2 I have a program communicating on a serial line like the following (excerpt): { os.write(command); os.flush(); // Thread.sleep(period); // read response while(is.available() > 0) { is.read() } } If there is a sleep between the os.flush and the reading cycle the correct answer is received. Otherwise (sometimes) there are extra, erronous characters at the beginning of the answer, but the correct answer (according to the protocol) also arrives, afterwards. Is this a normal behaviour, one should wait before the read? If yes, is there a way to determine the minimum amount of time to wait for? Serial port params are: 9600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE. Thank you in advance, Alex ________________________________________________________ El?foglal?si akci? meghosszabb?tva! Korfui ?d?l?s m?r 56.910 Ft-t?l. http://www.budavartours.hu/gorogorszag/?utm_campaign=origo&utm_source=freemail_kimeno_090403&utm_medium=ct&utm_content=korfu_elofoglalasi_akcio#reg_Korfu -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090403/8f3650ea/attachment-0011.html From bill7007 at gmail.com Fri Apr 3 16:15:30 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Fri, 3 Apr 2009 18:15:30 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: <49D546F8.20807@gatworks.com> Message-ID: > When perceived runability is hung, try a ^\ ( control \) on console. >> This gets the JVM to dump the stacks of all the java threads. > > Good idea... A thread dump is below, it looks like only some system threads are in wait state which is probably normal. The "main" thread is stopped writing the first data out the serial port which should complete but its has stopped at: at gnu.io.RXTXPort.nativeDrain(Native Method) It show its state as runnable though. There is another thread, "SerialReader_22", that is waiting to read any data on the same port. I'll bring the app up under Netbeans debugger next. >> > I've also noticed some linux systems hanging with open/read/write and saw > kacpid storms. No CPU use going when it hangs, acts like a deadlock. THREAD DUMP AT HANG: Entering RXTXPort:SerialOutputStream:write(4) writeArray() Leaving RXTXPort:SerialOutputStream:write(4) RXTXPort:SerialOutputStream:flush() enter RXTXPort:SerialInputStream:read(8192 0 8192) called Full thread dump Java HotSpot(TM) Client VM (1.5.0_06-b05 mixed mode, sharing): "SerialReader_22" daemon prio=1 tid=0x087abf38 nid=0x3c8b runnable [0xb1a43000..0xb1a43f30] at gnu.io.RXTXPort.readArray(Native Method) at gnu.io.RXTXPort$SerialInputStream.read(RXTXPort.java:1454) - locked <0x88ca55b8> (a gnu.io.RXTXPort$SerialInputStream) at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:411) at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) - locked <0x88cab378> (a java.io.InputStreamReader) at java.io.InputStreamReader.read(InputStreamReader.java:167) at java.io.BufferedReader.fill(BufferedReader.java:136) at java.io.BufferedReader.readLine(BufferedReader.java:299) - locked <0x88cab378> (a java.io.InputStreamReader) at java.io.BufferedReader.readLine(BufferedReader.java:362) at qms.TSerialPort$SerialRead.run(TSerialPort.java:268) at java.lang.Thread.run(Thread.java:595) "Thread-1" prio=1 tid=0x08a43360 nid=0x3c8a runnable [0xb1ac4000..0xb1ac4db0] at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1641) "AWT-XAWT" daemon prio=1 tid=0x08acc848 nid=0x3c87 runnable [0xb1b45000..0xb1b45e30] at sun.awt.X11.XToolkit.waitForEvents(Native Method) at sun.awt.X11.XToolkit.run(XToolkit.java:463) at sun.awt.X11.XToolkit.run(XToolkit.java:438) at java.lang.Thread.run(Thread.java:595) "Java2D Disposer" daemon prio=1 tid=0x08ab9d30 nid=0x3c86 in Object.wait() [0xb1bc6000..0xb1bc70b0] at java.lang.Object.wait(Native Method) - waiting on <0x8917b110> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:116) - locked <0x8917b110> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:132) at sun.java2d.Disposer.run(Disposer.java:107) at java.lang.Thread.run(Thread.java:595) "Low Memory Detector" daemon prio=1 tid=0x087bea68 nid=0x3c84 runnable [0x00000000..0x00000000] "CompilerThread0" daemon prio=1 tid=0x087bd4c0 nid=0x3c83 waiting on condition [0x00000000..0xb23a7a18] "Signal Dispatcher" daemon prio=1 tid=0x087bc520 nid=0x3c82 runnable [0x00000000..0x00000000] "Finalizer" daemon prio=1 tid=0x087b5710 nid=0x3c81 in Object.wait() [0xb26a9000..0xb26a9f30] at java.lang.Object.wait(Native Method) - waiting on <0x8914a770> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:116) - locked <0x8914a770> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:132) at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159) "Reference Handler" daemon prio=1 tid=0x087b49c8 nid=0x3c80 in Object.wait() [0xb272a000..0xb272adb0] at java.lang.Object.wait(Native Method) - waiting on <0x8914a7f0> (a java.lang.ref.Reference$Lock) at java.lang.Object.wait(Object.java:474) at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116) - locked <0x8914a7f0> (a java.lang.ref.Reference$Lock) "main" prio=1 tid=0x08777b88 nid=0x3c7e runnable [0xbffa7000..0xbffa74f8] at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1248) at qms.TSerialPort.Transmit(TSerialPort.java:192) - locked <0x88c99a68> (a qms.TSerialPort) at qms.TIOBoard.GetIOBoardVersion(TIOBoard.java:168) at qms.TIOBoard.(TIOBoard.java:73) at qms.TQMS.(TQMS.java:47) at qms.MainForm.(MainForm.java:2076) at qms.MainForm.main(MainForm.java:2099) "VM Thread" prio=1 tid=0x087b1e20 nid=0x3c7f runnable "VM Periodic Task Thread" prio=1 tid=0x087bff50 nid=0x3c85 waiting on condition -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090403/20b7bca4/attachment-0010.html From Martin.Oberhuber at windriver.com Fri Apr 3 16:23:43 2009 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Sat, 4 Apr 2009 00:23:43 +0200 Subject: [Rxtx] Missing documentation In-Reply-To: <49D5973E.4050400@bbs.darktech.org> References: <49D43979.4050702@bbs.darktech.org> <49D5973E.4050400@bbs.darktech.org> Message-ID: <460801A4097E3D4CA04CC64EE648584809C8BD6F@ism-mail03.corp.ad.wrs.com> Hello Gili, The classes in the gnu.io namespace are designed to work exactly as their counterparts in the javax.comm namespace. Therefore, if you just take the javax.comm Javadocs that's what you want. Unfortunately I don't think we can just copy & paste the javax.comm Javadocs into RXTX due to license restrictions. I guess that's the main reason why RXTX is not (yet) Javadoc'd as extensively as it should be. Actually, writing Javadocs from scratch WITHOUT referencing the wording of the Sun Javadocs is not that easy. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of cowwoc > Sent: Freitag, 03. April 2009 06:58 > To: rxtx at qbang.org > Subject: [Rxtx] Missing documentation > > Hi, > > I noticed that RXTX 2.1 drops javax.comm support in favor > of gnu.io. > I have one major problem with this: the gui.io.* > documentation is very > poor. Many classes and methods have no Javadoc at all which > makes them > difficult to use. Please fix this for the final release. > > Thank you, > Gili > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Fri Apr 3 16:54:50 2009 From: netbeans at gatworks.com (U. George) Date: Fri, 03 Apr 2009 18:54:50 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: <49D546F8.20807@gatworks.com> Message-ID: <49D693BA.8060909@gatworks.com> I would have tried 2 or 3 "^\" . If things are stuck, then all will be at same 'java' instruction. If thread is moving, then one of the snapshots would be different. I *think* flushing/draining wont return until the kernel buffers to device have been accepted by device. Stuck/paused device? Bill Johnson wrote: > > > > > When perceived runability is hung, try a ^\ ( control \) on console. > This gets the JVM to dump the stacks of all the java threads. > > > Good idea... A thread dump is below, it looks like only some system > threads are in wait state which is prob From cowwoc at bbs.darktech.org Fri Apr 3 17:45:09 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Fri, 03 Apr 2009 19:45:09 -0400 Subject: [Rxtx] Missing documentation In-Reply-To: <460801A4097E3D4CA04CC64EE648584809C8BD6F@ism-mail03.corp.ad.wrs.com> References: <49D43979.4050702@bbs.darktech.org> <49D5973E.4050400@bbs.darktech.org> <460801A4097E3D4CA04CC64EE648584809C8BD6F@ism-mail03.corp.ad.wrs.com> Message-ID: <49D69F85.3030804@bbs.darktech.org> You could always send Sun a formal email and ask for permission to copy their Javadoc. I doubt they would give you problems. Gili Oberhuber, Martin wrote: > Hello Gili, > > The classes in the gnu.io namespace are designed to work exactly > as their counterparts in the javax.comm namespace. Therefore, > if you just take the javax.comm Javadocs that's what you want. > > Unfortunately I don't think we can just copy & paste the > javax.comm Javadocs into RXTX due to license restrictions. > > I guess that's the main reason why RXTX is not (yet) Javadoc'd > as extensively as it should be. Actually, writing Javadocs > from scratch WITHOUT referencing the wording of the Sun > Javadocs is not that easy. > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] >> On Behalf Of cowwoc >> Sent: Freitag, 03. April 2009 06:58 >> To: rxtx at qbang.org >> Subject: [Rxtx] Missing documentation >> >> Hi, >> >> I noticed that RXTX 2.1 drops javax.comm support in favor >> of gnu.io. >> I have one major problem with this: the gui.io.* >> documentation is very >> poor. Many classes and methods have no Javadoc at all which >> makes them >> difficult to use. Please fix this for the final release. >> >> Thank you, >> Gili >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> From cowwoc at bbs.darktech.org Sat Apr 4 15:13:38 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sat, 04 Apr 2009 17:13:38 -0400 Subject: [Rxtx] Java5 support Message-ID: <49D7CD82.1040904@bbs.darktech.org> Now that you dropped javax.comm support, how about improving the API by replacing Enumation by Iterator, int by enum, and using Generics? It would improve the usability of the API. Gili From cowwoc at bbs.darktech.org Sat Apr 4 16:12:13 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sat, 04 Apr 2009 18:12:13 -0400 Subject: [Rxtx] RXTX Version mismatch in 2.2pre2 Message-ID: <49D7DB3D.5040008@bbs.darktech.org> When using RXTX-2.2pre2 I always get the following message: WARNING: RXTX Version mismatch Jar version = RXTX-2.2pre1 native lib Version = RXTX-2.2pre2 I have double checked that I am using the correct Jar file. Is this a known bug in pre2? Gili From tjarvi at qbang.org Sat Apr 4 16:48:53 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Apr 2009 16:48:53 -0600 (MDT) Subject: [Rxtx] RXTX Version mismatch in 2.2pre2 In-Reply-To: <49D7DB3D.5040008@bbs.darktech.org> References: <49D7DB3D.5040008@bbs.darktech.org> Message-ID: > When using RXTX-2.2pre2 I always get the following message: > > WARNING: RXTX Version mismatch > Jar version = RXTX-2.2pre1 > native lib Version = RXTX-2.2pre2 > Yep. You should still be able to test it. -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Sat Apr 4 16:50:43 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sat, 04 Apr 2009 18:50:43 -0400 Subject: [Rxtx] RXTX Version mismatch in 2.2pre2 In-Reply-To: References: <49D7DB3D.5040008@bbs.darktech.org> Message-ID: <49D7E443.9070404@bbs.darktech.org> In other words this is a known bug that will be fixed in the final version? Gili Trent Jarvi wrote: > > >> When using RXTX-2.2pre2 I always get the following message: >> >> WARNING: RXTX Version mismatch >> Jar version = RXTX-2.2pre1 >> native lib Version = RXTX-2.2pre2 >> > > Yep. > > You should still be able to test it. > > -- > Trent Jarvi > tjarvi at qbang.org From cowwoc at bbs.darktech.org Sat Apr 4 16:57:34 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sat, 04 Apr 2009 18:57:34 -0400 Subject: [Rxtx] IOException: Underlying input stream returned zero bytes Message-ID: <49D7E5DE.2050405@bbs.darktech.org> Hi, There seems to be a bug in RXTX 2.2pre2's handling of InputStream timeouts. If you open a serial port without ever invoking enableReceiveTimeout() then invoking InputStream.read() will always return 0 bytes right away. If you wrap the InputStream and invoke BufferedReader.readline() you will get the following exception: java.io.IOException: Underlying input stream returned zero bytes at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:268) [na:1.6.0_14-ea] at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:306) [na:1.6.0_14-ea] at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:158) [na:1.6.0_14-ea] at java.io.InputStreamReader.read(InputStreamReader.java:167) [na:1.6.0_14-ea] at java.io.BufferedReader.fill(BufferedReader.java:136) [na:1.6.0_14-ea] at java.io.BufferedReader.readLine(BufferedReader.java:299) [na:1.6.0_14-ea] at java.io.BufferedReader.readLine(BufferedReader.java:362) [na:1.6.0_14-ea] [snip] If you enable a timeout, the exception will only occur after the timeout expires. In short, it looks like RXTX is using a default timeout of zero (I am expecting it to block forever). It looks like other people have run into this as well: http://forums.sun.com/thread.jspa?threadID=5165346&start=10&tstart=0 Please confirm whether this is a known bug. Thank you, Gili From tjarvi at qbang.org Sat Apr 4 17:27:19 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Apr 2009 17:27:19 -0600 (MDT) Subject: [Rxtx] IOException: Underlying input stream returned zero bytes In-Reply-To: <49D7E5DE.2050405@bbs.darktech.org> References: <49D7E5DE.2050405@bbs.darktech.org> Message-ID: On Sat, 4 Apr 2009, cowwoc wrote: > Hi, > > There seems to be a bug in RXTX 2.2pre2's handling of InputStream > timeouts. If you open a serial port without ever invoking > enableReceiveTimeout() then invoking InputStream.read() will always > return 0 bytes right away. If you wrap the InputStream and invoke > BufferedReader.readline() you will get the following exception: > > java.io.IOException: Underlying input stream returned zero bytes > at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:268) > [na:1.6.0_14-ea] > at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:306) > [na:1.6.0_14-ea] > at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:158) > [na:1.6.0_14-ea] > at java.io.InputStreamReader.read(InputStreamReader.java:167) > [na:1.6.0_14-ea] > at java.io.BufferedReader.fill(BufferedReader.java:136) > [na:1.6.0_14-ea] > at java.io.BufferedReader.readLine(BufferedReader.java:299) > [na:1.6.0_14-ea] > at java.io.BufferedReader.readLine(BufferedReader.java:362) > [na:1.6.0_14-ea] > [snip] > > If you enable a timeout, the exception will only occur after the > timeout expires. In short, it looks like RXTX is using a default timeout > of zero (I am expecting it to block forever). It looks like other people > have run into this as well: > http://forums.sun.com/thread.jspa?threadID=5165346&start=10&tstart=0 > > Please confirm whether this is a known bug. > Hi Gili I've known about it but was not sure if it was a bug or not. It looks like we can treat it as a bug if nio is throwing an exception. Timeout and Thresholds are well documented in javax.comm but I didn't recall seeing defaults. For that reason, I've encouraged people to set the threshold and timeout to what they expect. Another note about InputStream.read(void): I noticed that I don't use that function at all while looking at code coverage results. Keep your eye out for additional issues. -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Sat Apr 4 19:03:29 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sat, 04 Apr 2009 21:03:29 -0400 Subject: [Rxtx] IOException: Underlying input stream returned zero bytes In-Reply-To: References: <49D7E5DE.2050405@bbs.darktech.org> Message-ID: <49D80361.7020801@bbs.darktech.org> Trent Jarvi wrote: > For that reason, I've encouraged people to set the threshold and timeout > to what they expect. It doesn't help. There doesn't seem to be a way to disable the timeout, even if you invoke disableReceiveTimeout() explicitly. Let me know when you put in a fix and I will test it. Thanks, Gili From cowwoc at bbs.darktech.org Sat Apr 4 23:27:25 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 01:27:25 -0400 Subject: [Rxtx] Crash in termios.c:892 Message-ID: <49D8413D.7040105@bbs.darktech.org> I can reproduce a crash in RXTX 2.2 pre2 100% of the time using my application code, but I can't seem to bring it down to a minimal testcase. Here is what I see: - thread begins running - open com1 - close com1 - open com5 - leave com5 open - thread shuts down - repeat the same process in a new thread - crash occurs when trying to open com1. Crash disappears if I close() com5 in the previous thread. The output window contains the following: # # A fatal error has been detected by the Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x05475cf6, pid=6064, tid=5436 # # JRE version: 6.0_14-b04 # Java VM: Java HotSpot(TM) Client VM (14.0-b13 mixed mode, sharing windows-x86 ) # Problematic frame: # C [rxtxSerial.dll+0x5cf6] # # An error report file with more information is saved as: # C:\Users\Gili\Documents\foobar\source\hs_err_pid6064.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp Error 0x5 at ..\src\termios.c(892): Access is denied. # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # Please let me know if the crash dump is enough to track down this bug. Thank you, Gili -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: hs_err_pid6064.log Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20090405/7133a1ce/attachment-0007.pl From cowwoc at bbs.darktech.org Sun Apr 5 00:24:19 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 02:24:19 -0400 Subject: [Rxtx] SerialPort.getName() is wrong Message-ID: <49D84E93.7050606@bbs.darktech.org> Sorry for all these emails but I keep on running into more issues. Here is what I noticed: - CommPortIdentifier.getPortIdentifier("COM5") returns a CommPortIdentifier where getName() == "COM5" - If, however, you invoke CommPortIdentifier.open() you get back a SerialPort where SerialPort.getName() is "//./COM5" I am expecting the name to remain consistent. "//./COM5" looks like an implementation detail and (as far as I can tell) it can't be used as an argument for any API method so it is somewhat useless. If getName() were to return "COM5" I could at least use it to get back the original CommPortIdentifier or compare against "known names" such as "COMx" or "LPTx". What do you think? Gili From tjarvi at qbang.org Sun Apr 5 10:18:42 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Apr 2009 10:18:42 -0600 (MDT) Subject: [Rxtx] SerialPort.getName() is wrong In-Reply-To: <49D84E93.7050606@bbs.darktech.org> References: <49D84E93.7050606@bbs.darktech.org> Message-ID: On Sun, 5 Apr 2009, cowwoc wrote: > > Sorry for all these emails but I keep on running into more issues. > Here is what I noticed: > > - CommPortIdentifier.getPortIdentifier("COM5") returns a > CommPortIdentifier where getName() == "COM5" > - If, however, you invoke CommPortIdentifier.open() you get back a > SerialPort where SerialPort.getName() is "//./COM5" > > I am expecting the name to remain consistent. "//./COM5" looks like > an implementation detail and (as far as I can tell) it can't be used as > an argument for any API method so it is somewhat useless. If getName() > were to return "COM5" I could at least use it to get back the original > CommPortIdentifier or compare against "known names" such as "COMx" or > "LPTx". What do you think? > Sure. If it itches enough you should be able to fix this in RXTXCommDriver.java. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Apr 5 10:27:58 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Apr 2009 10:27:58 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D8413D.7040105@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> Message-ID: On Sun, 5 Apr 2009, cowwoc wrote: > > I can reproduce a crash in RXTX 2.2 pre2 100% of the time using my > application code, but I can't seem to bring it down to a minimal testcase. > Here is what I see: > > - thread begins running > - open com1 > - close com1 > - open com5 > - leave com5 open > - thread shuts down > - repeat the same process in a new thread > - crash occurs when trying to open com1. Crash disappears if I close() com5 > in the previous thread. > > The output window contains the following: > > # > # A fatal error has been detected by the Java Runtime Environment: > # > # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x05475cf6, pid=6064, > tid=5436 > # > # JRE version: 6.0_14-b04 > # Java VM: Java HotSpot(TM) Client VM (14.0-b13 mixed mode, sharing > windows-x86 ) > # Problematic frame: > # C [rxtxSerial.dll+0x5cf6] > # > # An error report file with more information is saved as: > # C:\Users\Gili\Documents\foobar\source\hs_err_pid6064.log > # > # If you would like to submit a bug report, please visit: > # http://java.sun.com/webapps/bugreport/crash.jsp > Error 0x5 at ..\src\termios.c(892): Access is denied. > > > # The crash happened outside the Java Virtual Machine in native code. > # See problematic frame for where to report the bug. > # > > Please let me know if the crash dump is enough to track down this bug. > Hi Gili, You are responsible for cleaning up the serial ports when using threads. That said, if the thread did shut down, finalize should have been called if you are not passing the object around. See RXTXPort.java. protected void finalize() { if (debug) z.reportln( "RXTXPort:finalize()"); if( fd > 0 ) { if (debug) z.reportln( "RXTXPort:calling close()"); close(); } z.finalize(); } The exception is interesting. This is on Vista? Usually it just gives an open error when another process has the port. -- Trent Jarvi tjarvi at mathworks.com From cowwoc at bbs.darktech.org Sun Apr 5 10:35:55 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 12:35:55 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: References: <49D8413D.7040105@bbs.darktech.org> Message-ID: <49D8DDEB.5010908@bbs.darktech.org> Trent Jarvi wrote: > You are responsible for cleaning up the serial ports when using threads. > That said, if the thread did shut down, finalize should have been called > if you are not passing the object around. See RXTXPort.java. > > protected void finalize() > { > if (debug) > z.reportln( "RXTXPort:finalize()"); > if( fd > 0 ) > { > if (debug) > z.reportln( "RXTXPort:calling close()"); > close(); > } > z.finalize(); > } Two points: 1) One should never rely on finalizers because they may never run. 2) RXTX shouldn't cause the entire JVM to crash if I misuse the API. The native code should recover more gracefully. > The exception is interesting. This is on Vista? Usually it just gives > an open error when another process has the port. Yes, this is on Vista 64-bit. I'd really like to see this bug fixed. Is this code compilable under Visual Studio? If so, I can debug the problem on my end and send you a patch. Thanks, Gili From cowwoc at bbs.darktech.org Sun Apr 5 10:36:20 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 12:36:20 -0400 Subject: [Rxtx] SerialPort.getName() is wrong In-Reply-To: References: <49D84E93.7050606@bbs.darktech.org> Message-ID: <49D8DE04.6030306@bbs.darktech.org> Trent Jarvi wrote: >> I am expecting the name to remain consistent. "//./COM5" looks like >> an implementation detail and (as far as I can tell) it can't be used as >> an argument for any API method so it is somewhat useless. If getName() >> were to return "COM5" I could at least use it to get back the original >> CommPortIdentifier or compare against "known names" such as "COMx" or >> "LPTx". What do you think? >> > > Sure. > > If it itches enough you should be able to fix this in RXTXCommDriver.java. I'm not sure I understand. Are you saying that if I submit a patch you will commit it? Gili From tjarvi at qbang.org Sun Apr 5 10:46:23 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Apr 2009 10:46:23 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D8DDEB.5010908@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> Message-ID: On Sun, 5 Apr 2009, cowwoc wrote: > Trent Jarvi wrote: >> You are responsible for cleaning up the serial ports when using threads. >> That said, if the thread did shut down, finalize should have been called if >> you are not passing the object around. See RXTXPort.java. >> >> protected void finalize() >> { >> if (debug) >> z.reportln( "RXTXPort:finalize()"); >> if( fd > 0 ) >> { >> if (debug) >> z.reportln( "RXTXPort:calling close()"); >> close(); >> } >> z.finalize(); >> } > > Two points: > > 1) One should never rely on finalizers because they may never run. > 2) RXTX shouldn't cause the entire JVM to crash if I misuse the API. The > native code should recover more gracefully. > >> The exception is interesting. This is on Vista? Usually it just gives an >> open error when another process has the port. > > Yes, this is on Vista 64-bit. I'd really like to see this bug fixed. > Is this code compilable under Visual Studio? If so, I can debug the problem > on my end and send you a patch. > It will compile with the msvc cl.exe and nmake. See Makefile.msvc in the top level directory. You will need to adjust the JAVA_HOME variable. Also use the MSVC command prompt for x86_64 so cl and nmake are on your path. All the best, -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Apr 5 10:49:10 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Apr 2009 10:49:10 -0600 (MDT) Subject: [Rxtx] SerialPort.getName() is wrong In-Reply-To: <49D8DE04.6030306@bbs.darktech.org> References: <49D84E93.7050606@bbs.darktech.org> <49D8DE04.6030306@bbs.darktech.org> Message-ID: On Sun, 5 Apr 2009, cowwoc wrote: > Trent Jarvi wrote: >>> I am expecting the name to remain consistent. "//./COM5" looks like >>> an implementation detail and (as far as I can tell) it can't be used as >>> an argument for any API method so it is somewhat useless. If getName() >>> were to return "COM5" I could at least use it to get back the original >>> CommPortIdentifier or compare against "known names" such as "COMx" or >>> "LPTx". What do you think? >>> >> >> Sure. >> >> If it itches enough you should be able to fix this in RXTXCommDriver.java. > > I'm not sure I understand. Are you saying that if I submit a patch > you will commit it? > Hi Gili, Post a patch here and if nobody complains, we will commit it and give you credit. Yep. Other issues like changing the API to use java5 that may break existing apps are likely to run into objections but bug fixes usually get fixed just as you mention. -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Sun Apr 5 10:55:07 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 12:55:07 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> Message-ID: <49D8E26B.2040705@bbs.darktech.org> Trent Jarvi wrote: > It will compile with the msvc cl.exe and nmake. See Makefile.msvc in > the top level directory. You will need to adjust the JAVA_HOME > variable. Also use the MSVC command prompt for x86_64 so cl and nmake > are on your path. This is very odd. The CVS version of the code does not contain this file. Do you keep the latest code somewhere else? Gili From cowwoc at bbs.darktech.org Sun Apr 5 11:01:58 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 13:01:58 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D8E26B.2040705@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> Message-ID: <49D8E406.10708@bbs.darktech.org> cowwoc wrote: > Trent Jarvi wrote: >> It will compile with the msvc cl.exe and nmake. See Makefile.msvc in >> the top level directory. You will need to adjust the JAVA_HOME >> variable. Also use the MSVC command prompt for x86_64 so cl and nmake >> are on your path. > > This is very odd. The CVS version of the code does not contain this > file. Do you keep the latest code somewhere else? Okay I figured it out. CVS head is out of date, the "commapi-0-0-1" revision contains the correct files. Gili From tjarvi at qbang.org Sun Apr 5 11:05:43 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Apr 2009 11:05:43 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D8E26B.2040705@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> Message-ID: CVS HEAD is currently the rxtx 2.0 code. A branch was created long ago for 'experimental' gnu.io work. It just happens that the branch is what everyone uses now. checkout -r commapi-0-0-1 rxtx-devel will get the branch On Sun, 5 Apr 2009, cowwoc wrote: > Trent Jarvi wrote: >> It will compile with the msvc cl.exe and nmake. See Makefile.msvc in the >> top level directory. You will need to adjust the JAVA_HOME variable. Also >> use the MSVC command prompt for x86_64 so cl and nmake are on your path. > > This is very odd. The CVS version of the code does not contain this > file. Do you keep the latest code somewhere else? > > Gili > From cowwoc at bbs.darktech.org Sun Apr 5 14:50:47 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 16:50:47 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> Message-ID: <49D919A7.1070806@bbs.darktech.org> Okay, I tracked down the crash. It's being caused by YACK() using a 80-character buffer. The error message is longer than 80 characters, so _snprintf_s() crashes to avoid a buffer overflow. Please apply the attached patch and add the zipped up Visual Studio project directory. It's not perfect yet but it's a good start. Gili Trent Jarvi wrote: > > CVS HEAD is currently the rxtx 2.0 code. A branch was created long > ago for 'experimental' gnu.io work. It just happens that the branch > is what everyone uses now. > > checkout -r commapi-0-0-1 rxtx-devel > > will get the branch > > On Sun, 5 Apr 2009, cowwoc wrote: > >> Trent Jarvi wrote: >>> It will compile with the msvc cl.exe and nmake. See Makefile.msvc >>> in the top level directory. You will need to adjust the JAVA_HOME >>> variable. Also use the MSVC command prompt for x86_64 so cl and >>> nmake are on your path. >> >> This is very odd. The CVS version of the code does not contain >> this file. Do you keep the latest code somewhere else? >> >> Gili >> -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx-devel.patch Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20090405/d9b82962/attachment-0006.pl -------------- next part -------------- A non-text attachment was scrubbed... Name: Win32.zip Type: application/octet-stream Size: 17764 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20090405/d9b82962/attachment-0008.obj From cowwoc at bbs.darktech.org Sun Apr 5 15:22:01 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 17:22:01 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D919A7.1070806@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> <49D919A7.1070806@bbs.darktech.org> Message-ID: <49D920F9.6080702@bbs.darktech.org> My mistake. The problem in YACK is real, but it isn't the real cause of the crash. The crash is caused by termios.c line 1099: index->prev->next = port; because in my case "index->prev==0". I think the bug is that the code assumes that index will contain a minimum of two entries if we're inserting a previously closed fd. In my case, it only contains one. I'm not sure why you have this code branch (as opposed to appending to the end of index). Please take a look. Thanks, Gili cowwoc wrote: > > Okay, I tracked down the crash. It's being caused by YACK() using a > 80-character buffer. The error message is longer than 80 characters, so > _snprintf_s() crashes to avoid a buffer overflow. > > Please apply the attached patch and add the zipped up Visual Studio > project directory. It's not perfect yet but it's a good start. > > Gili > > Trent Jarvi wrote: >> >> CVS HEAD is currently the rxtx 2.0 code. A branch was created long >> ago for 'experimental' gnu.io work. It just happens that the branch >> is what everyone uses now. >> >> checkout -r commapi-0-0-1 rxtx-devel >> >> will get the branch >> >> On Sun, 5 Apr 2009, cowwoc wrote: >> >>> Trent Jarvi wrote: >>>> It will compile with the msvc cl.exe and nmake. See Makefile.msvc >>>> in the top level directory. You will need to adjust the JAVA_HOME >>>> variable. Also use the MSVC command prompt for x86_64 so cl and >>>> nmake are on your path. >>> >>> This is very odd. The CVS version of the code does not contain >>> this file. Do you keep the latest code somewhere else? >>> >>> Gili >>> From tjarvi at qbang.org Sun Apr 5 16:13:27 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Apr 2009 16:13:27 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D920F9.6080702@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> <49D919A7.1070806@bbs.darktech.org> <49D920F9.6080702@bbs.darktech.org> Message-ID: Hi Gili, Are you using the cvs version? I thought we fixed the linked list issues. A solution was posted to the list. Let me look at work tomorrow to see what I have. On Sun, 5 Apr 2009, cowwoc wrote: > > My mistake. The problem in YACK is real, but it isn't the real cause > of the crash. The crash is caused by termios.c line 1099: > > index->prev->next = port; > > because in my case "index->prev==0". I think the bug is that the code > assumes that index will contain a minimum of two entries if we're inserting a > previously closed fd. In my case, it only contains one. > > I'm not sure why you have this code branch (as opposed to appending > to the end of index). Please take a look. > > Thanks, > Gili > > cowwoc wrote: >> >> Okay, I tracked down the crash. It's being caused by YACK() using a >> 80-character buffer. The error message is longer than 80 characters, so >> _snprintf_s() crashes to avoid a buffer overflow. >> >> Please apply the attached patch and add the zipped up Visual Studio >> project directory. It's not perfect yet but it's a good start. >> >> Gili >> >> Trent Jarvi wrote: >>> >>> CVS HEAD is currently the rxtx 2.0 code. A branch was created long ago >>> for 'experimental' gnu.io work. It just happens that the branch is what >>> everyone uses now. >>> >>> checkout -r commapi-0-0-1 rxtx-devel >>> >>> will get the branch >>> >>> On Sun, 5 Apr 2009, cowwoc wrote: >>> >>>> Trent Jarvi wrote: >>>>> It will compile with the msvc cl.exe and nmake. See Makefile.msvc in >>>>> the top level directory. You will need to adjust the JAVA_HOME >>>>> variable. Also use the MSVC command prompt for x86_64 so cl and nmake >>>>> are on your path. >>>> >>>> This is very odd. The CVS version of the code does not contain this >>>> file. Do you keep the latest code somewhere else? >>>> >>>> Gili >>>> > From ilkka at myller.com Sun Apr 5 23:58:08 2009 From: ilkka at myller.com (Ilkka Myller) Date: Mon, 6 Apr 2009 08:58:08 +0300 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> <49D919A7.1070806@bbs.darktech.org> <49D920F9.6080702@bbs.darktech.org> Message-ID: <19779C97-E0C7-4E3D-B715-F84F50F00CE6@myller.com> Hi all, I've already submitted the patch to fix this issue in february: http://mailman.qbang.org/pipermail/rxtx/2009-February/3989441.html The patch fixes the mentioned doubly linked list handling in termios.c -- I Trent Jarvi kirjoitti 6.4.2009 kello 1.13: > > Hi Gili, > > Are you using the cvs version? I thought we fixed the linked list > issues. > A solution was posted to the list. Let me look at work tomorrow to > see > what I have. > > > > On Sun, 5 Apr 2009, cowwoc wrote: > >> >> My mistake. The problem in YACK is real, but it isn't the real cause >> of the crash. The crash is caused by termios.c line 1099: >> >> index->prev->next = port; >> >> because in my case "index->prev==0". I think the bug is that the >> code >> assumes that index will contain a minimum of two entries if we're >> inserting a >> previously closed fd. In my case, it only contains one. >> >> I'm not sure why you have this code branch (as opposed to appending >> to the end of index). Please take a look. >> >> Thanks, >> Gili >> >> cowwoc wrote: >>> >>> Okay, I tracked down the crash. It's being caused by YACK() >>> using a >>> 80-character buffer. The error message is longer than 80 >>> characters, so >>> _snprintf_s() crashes to avoid a buffer overflow. >>> >>> Please apply the attached patch and add the zipped up Visual >>> Studio >>> project directory. It's not perfect yet but it's a good start. >>> >>> Gili >>> >>> Trent Jarvi wrote: >>>> >>>> CVS HEAD is currently the rxtx 2.0 code. A branch was created >>>> long ago >>>> for 'experimental' gnu.io work. It just happens that the branch >>>> is what >>>> everyone uses now. >>>> >>>> checkout -r commapi-0-0-1 rxtx-devel >>>> >>>> will get the branch >>>> >>>> On Sun, 5 Apr 2009, cowwoc wrote: >>>> >>>>> Trent Jarvi wrote: >>>>>> It will compile with the msvc cl.exe and nmake. See >>>>>> Makefile.msvc in >>>>>> the top level directory. You will need to adjust the JAVA_HOME >>>>>> variable. Also use the MSVC command prompt for x86_64 so cl and >>>>>> nmake >>>>>> are on your path. >>>>> >>>>> This is very odd. The CVS version of the code does not >>>>> contain this >>>>> file. Do you keep the latest code somewhere else? >>>>> >>>>> Gili >>>>> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Steffen.DETTMER at ingenico.com Mon Apr 6 02:53:47 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 6 Apr 2009 10:53:47 +0200 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D919A7.1070806@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> <49D919A7.1070806@bbs.darktech.org> Message-ID: <20090406085347.GM8289@elberon.bln.de.ingenico.com> Hi, just two minor details, first about the errno change, I though #include extern int errno; is correct (POSIX.1) - why this change? second about the log message, I think the maximum length could be limited and the return value of malloc must be checked for != NULL before using. Should it be _snprintf_s( message, 80, _TRUNCATE, "Error 0x%x at %s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); (I know that MS-CRT _snprintf does not guarantee to have a final EOS, but I think _snprintf_s with _TRUNCATE does so?). If it is known that truncation may happen maybe sizeof[message] could be increased; maybe using some %.20s could be used avoiding __FILE__ including big pathes to a message where all the message had been cut-off. To have it portable I think it could be: /* generally: */ #if defined(_MSC_VER) # define snprintf _snprintf #endif snprintf(message, sizeof(message), "Error 0x%x at %.20s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); message[sizeof(message)-1] = '\0'; /* needed for MS CRT snprintf */ (for length and size parameter I think size_t could be an option, but on several platforms, including MS-CRT and older glibc, there is no %z, unfortunately) oki, Steffen * cowwoc wrote on Sun, Apr 05, 2009 at 16:50 -0400: > > Okay, I tracked down the crash. It's being caused by YACK() using a > 80-character buffer. The error message is longer than 80 characters, so > _snprintf_s() crashes to avoid a buffer overflow. > > Please apply the attached patch and add the zipped up Visual Studio > project directory. It's not perfect yet but it's a good start. > > Gili > > Trent Jarvi wrote: > > > >CVS HEAD is currently the rxtx 2.0 code. A branch was created long > >ago for 'experimental' gnu.io work. It just happens that the branch > >is what everyone uses now. > > > >checkout -r commapi-0-0-1 rxtx-devel > > > >will get the branch > > > >On Sun, 5 Apr 2009, cowwoc wrote: > > > >>Trent Jarvi wrote: > >>>It will compile with the msvc cl.exe and nmake. See Makefile.msvc > >>>in the top level directory. You will need to adjust the JAVA_HOME > >>>variable. Also use the MSVC command prompt for x86_64 so cl and > >>>nmake are on your path. > >> > >> This is very odd. The CVS version of the code does not contain > >>this file. Do you keep the latest code somewhere else? > >> > >>Gili > >> > Index: ParallelImp.c > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/ParallelImp.c,v > retrieving revision 1.15.2.36 > diff -u -r1.15.2.36 ParallelImp.c > --- ParallelImp.c 11 Feb 2009 01:04:19 -0000 1.15.2.36 > +++ ParallelImp.c 5 Apr 2009 17:55:23 -0000 > @@ -119,7 +119,7 @@ > # include > #endif > > -extern int errno; > +_CRTIMP extern int * __cdecl _errno(void); > > #include "ParallelImp.h" > > @@ -181,8 +181,6 @@ > > #if defined (WIN32) > > -#define CTL_CODE( DeviceType, Function, Method, Access ) (((DeviceType) << 16) | ((Access) << 14) | ((Function) << 2) | (Method)) > - > #define FILE_DEVICE_PARALLEL_PORT 0x00000016 > #define METHOD_BUFFERED 0 > #define FILE_ANY_ACCESS 0 > @@ -253,7 +251,6 @@ > jobject jobj) > { > int fd = get_java_var( env, jobj,"fd","I" ); > - int status; > #if defined (__linux__) > ioctl(fd, LPGETSTATUS, &status); > #elif defined (WIN32) > Index: SerialImp.c > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v > retrieving revision 1.46.2.203 > diff -u -r1.46.2.203 SerialImp.c > --- SerialImp.c 19 Mar 2009 03:27:48 -0000 1.46.2.203 > +++ SerialImp.c 5 Apr 2009 17:49:48 -0000 > @@ -147,7 +147,7 @@ > #include > #endif /* LIBLOCKDEV */ > > -extern int errno; > +_CRTIMP extern int * __cdecl _errno(void); > > #include "SerialImp.h" > > Index: termios.c > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/termios.c,v > retrieving revision 1.9.2.62 > diff -u -r1.9.2.62 termios.c > --- termios.c 13 Jan 2009 03:08:55 -0000 1.9.2.62 > +++ termios.c 5 Apr 2009 17:54:09 -0000 > @@ -88,7 +88,7 @@ > #define SIGIO 0 > > int my_errno; > -extern int errno; > +_CRTIMP extern int * __cdecl _errno(void); > struct termios_list > { > char filename[80]; > @@ -1350,7 +1350,7 @@ > In that case use EAGAIN. See SerialImp.c:testRead() > ----------------------------------------------------------*/ > > -int serial_read( int fd, void *vb, int size ) > +int serial_read( int fd, void *vb, unsigned int size ) > { > long start, now; > unsigned long nBytes = 0, total = 0, error; > Index: win32termios.h > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/win32termios.h,v > retrieving revision 1.5.2.34 > diff -u -r1.5.2.34 win32termios.h > --- win32termios.h 5 Feb 2009 01:25:05 -0000 1.5.2.34 > +++ win32termios.h 5 Apr 2009 20:29:30 -0000 > @@ -60,6 +60,7 @@ > #include > #include > #include > +#include > #ifdef TRACE > #define ENTER(x) report("entering "x" \n"); > #define LEAVE(x) report("leaving "x" \n"); > @@ -70,8 +71,9 @@ > #if defined(_MSC_VER) > #define YACK() \ > { \ > - char *allocTextBuf, message[80]; \ > - unsigned long nChars; \ > + char *allocTextBuf, *message; \ > + const unsigned short longestNumber = 20; \ > + unsigned long nChars, len; \ > unsigned int errorCode = GetLastError(); \ > nChars = FormatMessage ( \ > FORMAT_MESSAGE_ALLOCATE_BUFFER | \ > @@ -82,8 +84,12 @@ > (LPSTR)&allocTextBuf, \ > 16, \ > NULL ); \ > - _snprintf_s( message, 80, 80, "Error 0x%x at %s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); \ > + len = strlen("Error 0x") + longestNumber + strlen(" at ") + strlen(__FILE__) + longestNumber + \ > + strlen(": ") + ((nChars+1) * sizeof(TCHAR)) + 1; \ > + message = malloc(len); \ > + _snprintf_s( message, len, len - 1, "Error 0x%x at %s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); \ > report_error( message ); \ > + free(message); \ > LocalFree(allocTextBuf); \ > Sleep(1); \ > } > @@ -173,7 +179,7 @@ > int serial_test( char * ); > int serial_open(const char *File, int flags, ... ); > int serial_close(int fd); > -int serial_read(int fd, void *b, int size); > +int serial_read(int fd, void *b, unsigned int size); > int serial_write(int fd, char *Str, int length); > /* > * lcc winsock.h conflicts > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx End of message. ------------------------------------------------------------------->8======= About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From bill7007 at gmail.com Mon Apr 6 16:34:50 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Mon, 6 Apr 2009 18:34:50 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: <49D693BA.8060909@gatworks.com> References: <49D546F8.20807@gatworks.com> <49D693BA.8060909@gatworks.com> Message-ID: Once it hung, three stack dumps minutes apart were exactly the same. I have a noticed that when it hangs, the read appears after flush() enter and before flush leave() that doesn't happen like: RXTXPort:SerialOutputStream:flush() enter RXTXPort:SerialInputStream:read(8192 0 8192) called When it works, flush() enter and leave happen together. It may just be because flush() hangs and read is the only other thread waiting to run at that point. I don't know much about the RXTX design and kernel interaction, just digging through the code some. Is there a design description somewhere? Am hung up on target system compile since UTS_RELEASE seems no longer defined for 2.6.18 up kernels and have not figured a good patch yet. But, that is another issue. Thanks for the good help. On Fri, Apr 3, 2009 at 6:54 PM, U. George wrote: > I would have tried 2 or 3 "^\" . If things are stuck, then all will be at > same 'java' instruction. If thread is moving, then one of the snapshots > would be different. > > I *think* flushing/draining wont return until the kernel buffers to device > have been accepted by device. Stuck/paused device? > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090406/c4b509d8/attachment-0007.html From tjarvi at qbang.org Mon Apr 6 17:45:38 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 6 Apr 2009 17:45:38 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <20090406085347.GM8289@elberon.bln.de.ingenico.com> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> <49D919A7.1070806@bbs.darktech.org> <20090406085347.GM8289@elberon.bln.de.ingenico.com> Message-ID: The error bits in the patch can probably just be dropped out. I don't see what they solve. Your snprintf define appears to work. The following is what I'd like to put in if noone objects. #if defined(_MSC_VER) # define snprintf _snprintf #endif #define YACK() \ { \ char *allocTextBuf, message[80]; \ unsigned long nChars; \ unsigned int errorCode = GetLastError(); \ nChars = FormatMessage ( \ FORMAT_MESSAGE_ALLOCATE_BUFFER | \ FORMAT_MESSAGE_FROM_SYSTEM, \ NULL, \ errorCode, \ MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT), \ (LPSTR)&allocTextBuf, \ 16, \ NULL ); \ snprintf( message, 80, "Error 0x%x at %s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); \ message[sizeof(message)-1] = '\0'; /* needed for MS CRT snprintf */ \ report_error( message ); \ LocalFree(allocTextBuf); \ Sleep(1); \ } On Mon, 6 Apr 2009, Steffen DETTMER wrote: > Hi, > > just two minor details, first about the errno change, I though > > #include > extern int errno; > > is correct (POSIX.1) - why this change? > > second about the log message, I think the maximum length could be > limited and the return value of malloc must be checked for != > NULL before using. > > Should it be > > _snprintf_s( message, 80, _TRUNCATE, "Error 0x%x at %s(%d): %s\n", > errorCode, __FILE__, __LINE__, allocTextBuf); > > (I know that MS-CRT _snprintf does not guarantee to have a final > EOS, but I think _snprintf_s with _TRUNCATE does so?). > > If it is known that truncation may happen maybe sizeof[message] > could be increased; maybe using some %.20s could be used avoiding > __FILE__ including big pathes to a message where all the message > had been cut-off. > > To have it portable I think it could be: > > /* generally: */ > #if defined(_MSC_VER) > # define snprintf _snprintf > #endif > > snprintf(message, sizeof(message), "Error 0x%x at %.20s(%d): %s\n", > errorCode, __FILE__, __LINE__, allocTextBuf); > message[sizeof(message)-1] = '\0'; /* needed for MS CRT snprintf */ > > (for length and size parameter I think size_t could be an option, > but on several platforms, including MS-CRT and older glibc, > there is no %z, unfortunately) > > oki, > > Steffen > > > * cowwoc wrote on Sun, Apr 05, 2009 at 16:50 -0400: >> >> Okay, I tracked down the crash. It's being caused by YACK() using a >> 80-character buffer. The error message is longer than 80 characters, so >> _snprintf_s() crashes to avoid a buffer overflow. >> >> Please apply the attached patch and add the zipped up Visual Studio >> project directory. It's not perfect yet but it's a good start. >> >> Gili >> >> Trent Jarvi wrote: >> > >> >CVS HEAD is currently the rxtx 2.0 code. A branch was created long >> >ago for 'experimental' gnu.io work. It just happens that the branch >> >is what everyone uses now. >> > >> >checkout -r commapi-0-0-1 rxtx-devel >> > >> >will get the branch >> > >> >On Sun, 5 Apr 2009, cowwoc wrote: >> > >> >>Trent Jarvi wrote: >> >>>It will compile with the msvc cl.exe and nmake. See Makefile.msvc >> >>>in the top level directory. You will need to adjust the JAVA_HOME >> >>>variable. Also use the MSVC command prompt for x86_64 so cl and >> >>>nmake are on your path. >> >> >> >> This is very odd. The CVS version of the code does not contain >> >>this file. Do you keep the latest code somewhere else? >> >> >> >>Gili >> >> > >> Index: ParallelImp.c >> =================================================================== >> RCS file: /usr/local/cvsroot/rxtx-devel/src/ParallelImp.c,v >> retrieving revision 1.15.2.36 >> diff -u -r1.15.2.36 ParallelImp.c >> --- ParallelImp.c 11 Feb 2009 01:04:19 -0000 1.15.2.36 >> +++ ParallelImp.c 5 Apr 2009 17:55:23 -0000 >> @@ -119,7 +119,7 @@ >> # include >> #endif >> >> -extern int errno; >> +_CRTIMP extern int * __cdecl _errno(void); >> >> #include "ParallelImp.h" >> >> @@ -181,8 +181,6 @@ >> >> #if defined (WIN32) >> >> -#define CTL_CODE( DeviceType, Function, Method, Access ) (((DeviceType) << 16) | ((Access) << 14) | ((Function) << 2) | (Method)) >> - >> #define FILE_DEVICE_PARALLEL_PORT 0x00000016 >> #define METHOD_BUFFERED 0 >> #define FILE_ANY_ACCESS 0 >> @@ -253,7 +251,6 @@ >> jobject jobj) >> { >> int fd = get_java_var( env, jobj,"fd","I" ); >> - int status; >> #if defined (__linux__) >> ioctl(fd, LPGETSTATUS, &status); >> #elif defined (WIN32) >> Index: SerialImp.c >> =================================================================== >> RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v >> retrieving revision 1.46.2.203 >> diff -u -r1.46.2.203 SerialImp.c >> --- SerialImp.c 19 Mar 2009 03:27:48 -0000 1.46.2.203 >> +++ SerialImp.c 5 Apr 2009 17:49:48 -0000 >> @@ -147,7 +147,7 @@ >> #include >> #endif /* LIBLOCKDEV */ >> >> -extern int errno; >> +_CRTIMP extern int * __cdecl _errno(void); >> >> #include "SerialImp.h" >> >> Index: termios.c >> =================================================================== >> RCS file: /usr/local/cvsroot/rxtx-devel/src/termios.c,v >> retrieving revision 1.9.2.62 >> diff -u -r1.9.2.62 termios.c >> --- termios.c 13 Jan 2009 03:08:55 -0000 1.9.2.62 >> +++ termios.c 5 Apr 2009 17:54:09 -0000 >> @@ -88,7 +88,7 @@ >> #define SIGIO 0 >> >> int my_errno; >> -extern int errno; >> +_CRTIMP extern int * __cdecl _errno(void); >> struct termios_list >> { >> char filename[80]; >> @@ -1350,7 +1350,7 @@ >> In that case use EAGAIN. See SerialImp.c:testRead() >> ----------------------------------------------------------*/ >> >> -int serial_read( int fd, void *vb, int size ) >> +int serial_read( int fd, void *vb, unsigned int size ) >> { >> long start, now; >> unsigned long nBytes = 0, total = 0, error; >> Index: win32termios.h >> =================================================================== >> RCS file: /usr/local/cvsroot/rxtx-devel/src/win32termios.h,v >> retrieving revision 1.5.2.34 >> diff -u -r1.5.2.34 win32termios.h >> --- win32termios.h 5 Feb 2009 01:25:05 -0000 1.5.2.34 >> +++ win32termios.h 5 Apr 2009 20:29:30 -0000 >> @@ -60,6 +60,7 @@ >> #include >> #include >> #include >> +#include >> #ifdef TRACE >> #define ENTER(x) report("entering "x" \n"); >> #define LEAVE(x) report("leaving "x" \n"); >> @@ -70,8 +71,9 @@ >> #if defined(_MSC_VER) >> #define YACK() \ >> { \ >> - char *allocTextBuf, message[80]; \ >> - unsigned long nChars; \ >> + char *allocTextBuf, *message; \ >> + const unsigned short longestNumber = 20; \ >> + unsigned long nChars, len; \ >> unsigned int errorCode = GetLastError(); \ >> nChars = FormatMessage ( \ >> FORMAT_MESSAGE_ALLOCATE_BUFFER | \ >> @@ -82,8 +84,12 @@ >> (LPSTR)&allocTextBuf, \ >> 16, \ >> NULL ); \ >> - _snprintf_s( message, 80, 80, "Error 0x%x at %s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); \ >> + len = strlen("Error 0x") + longestNumber + strlen(" at ") + strlen(__FILE__) + longestNumber + \ >> + strlen(": ") + ((nChars+1) * sizeof(TCHAR)) + 1; \ >> + message = malloc(len); \ >> + _snprintf_s( message, len, len - 1, "Error 0x%x at %s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); \ >> report_error( message ); \ >> + free(message); \ >> LocalFree(allocTextBuf); \ >> Sleep(1); \ >> } >> @@ -173,7 +179,7 @@ >> int serial_test( char * ); >> int serial_open(const char *File, int flags, ... ); >> int serial_close(int fd); >> -int serial_read(int fd, void *b, int size); >> +int serial_read(int fd, void *b, unsigned int size); >> int serial_write(int fd, char *Str, int length); >> /* >> * lcc winsock.h conflicts >> > > >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > > > > > > > > > > > > End of message. > ------------------------------------------------------------------->8======= > > > About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. > This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > P Please consider the environment before printing this e-mail > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Apr 6 18:11:28 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 6 Apr 2009 18:11:28 -0600 (MDT) Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: <49D546F8.20807@gatworks.com> <49D693BA.8060909@gatworks.com> Message-ID: UTS_RELEASE is defined in now. The check really should be removed from RXTX. It was a defensive check for wilder times when GNU glibc did not have defines the kernel headers had so rxtx would include the kernel headers instead. :/ If you don't have linux/version.h, it is generated when you configure the kernel. make oldconfig used to do the trick. It may make sense to work with the prerelease or CVS code. RXTX just assumes that flush, read and anything else the kernel exposes may be called at anytime from any thread. There isn't a design for the kernel interaction. There are higher level constraints put in Java to prevent some things happening at the same time with 'synchronized.' RXTXPort.java has all of those. When the port is opened, a native event thread is started which uses select to know if an event has happened. BSD like systems have a native thread that fires off on write which tries to flush() to determine when the output buffer is empty asynchronously. The rest is not marshaled in any fashion at the native level. T I think there is a lower level deadlock being triggered in flush as well. I don't think it should be possible if everything was right underneath us. You may want to examine the java code closer to make sure it isnt possible the lock is there. On Mon, 6 Apr 2009, Bill Johnson wrote: > Once it hung, three stack dumps minutes apart were exactly the same. > I have a noticed that when it hangs, the read appears after flush() enter and > before flush leave() that doesn't happen like: > RXTXPort:SerialOutputStream:flush() enter > RXTXPort:SerialInputStream:read(8192 0 8192) called > > When it works, flush() enter and leave happen together. It may just be because > flush() hangs and read is the only other thread waiting to run at that point. > I don't know much about the RXTX design and kernel interaction, just digging > through the code some. Is there a design description somewhere? > > Am hung up on target system compile since UTS_RELEASE seems no longer defined for > 2.6.18 up kernels and have not figured a good patch yet. But, that is another > issue. > > Thanks for the good help. > > > On Fri, Apr 3, 2009 at 6:54 PM, U. George wrote: > I would have tried 2 or 3 "^\" . If things are stuck, then all will be > at same 'java' instruction. If thread is moving, then one of the > snapshots would be different. > > I *think* flushing/draining wont return until the kernel buffers to > device have been accepted by device. Stuck/paused device? > > > > > From tjarvi at qbang.org Mon Apr 6 18:28:50 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 6 Apr 2009 18:28:50 -0600 (MDT) Subject: [Rxtx] CVS updates. Pre3 is comming. Message-ID: I need to go through the bugzilla reports prior to the pre3 release. I think this should be close if you want to check it out from CVS. added: YACK() debug overflow fix for windows Steffen DETTMER (and many others) multiport fix for windows. Ilkka Myller http://mailman.qbang.org/pipermail/rxtx/2009-February/3989441.html I think this code is current. If I missed something, yell. CVS Info: export/setenv CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login # passwd mousy cvs checkout -r commapi-0-0-1 rxtx-devel -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Apr 6 22:32:07 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 6 Apr 2009 22:32:07 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D919A7.1070806@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> <49D919A7.1070806@bbs.darktech.org> Message-ID: Ah. I'll put this in CVS tomorrow. I did sync up the code with my work sandbox today. I just forgot to pull and add this. On Sun, 5 Apr 2009, cowwoc wrote: > > Okay, I tracked down the crash. It's being caused by YACK() using a > 80-character buffer. The error message is longer than 80 characters, so > _snprintf_s() crashes to avoid a buffer overflow. > > Please apply the attached patch and add the zipped up Visual Studio > project directory. It's not perfect yet but it's a good start. > > Gili > > Trent Jarvi wrote: >> >> CVS HEAD is currently the rxtx 2.0 code. A branch was created long ago for >> 'experimental' gnu.io work. It just happens that the branch is what >> everyone uses now. >> >> checkout -r commapi-0-0-1 rxtx-devel >> >> will get the branch >> >> On Sun, 5 Apr 2009, cowwoc wrote: >> >>> Trent Jarvi wrote: >>>> It will compile with the msvc cl.exe and nmake. See Makefile.msvc in the >>>> top level directory. You will need to adjust the JAVA_HOME variable. >>>> Also use the MSVC command prompt for x86_64 so cl and nmake are on your >>>> path. >>> >>> This is very odd. The CVS version of the code does not contain this >>> file. Do you keep the latest code somewhere else? >>> >>> Gili >>> > From cowwoc at bbs.darktech.org Tue Apr 7 06:07:46 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Tue, 07 Apr 2009 08:07:46 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: References: Message-ID: <49DB4212.40807@bbs.darktech.org> > just two minor details, first about the errno change, I though > > #include > extern int errno; > > is correct (POSIX.1) - why this change? If you compile this under Visual Studio 2008 you will get warnings that the errno type being imported is different from the type being exported. The definition I pasted is the one being exported. Perhaps we should use #ifdef WIN32 for this? Gili From bill7007 at gmail.com Tue Apr 7 17:58:54 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Tue, 7 Apr 2009 19:58:54 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: <49D546F8.20807@gatworks.com> <49D693BA.8060909@gatworks.com> Message-ID: I have traced the hang down to a call to tcdrain(fd) in SerialImp.c:drain() running and rebuilt under Netbeans on the target machine with debug messages on. That puts it into the system code, so I'm not sure how to proceed. I guess I could debug into the kernel source but I've not done that. I saw some discussion about an IOCTL that sets/adjusts a timeout on tcdrain() but that may have been for BSD. Maybe there is some new setup requirement or bug introduced with this 2.6.18 kernel or a hardware difference. Below is a message listing with some of the repeated parts removed. Maybe you can see something noteworthy? JNI_OnLoad called. WARNING: RXTX Version mismatch Jar version = RXTX-2.2pre2 native lib Version = RXTX-2.2pre3 entering RXTXCommDriver:getDeviceDirectory entering RXTXPort:testRead fhs_lock: creating lockfile: 29704 fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXPort:testRead RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB2 fhs_lock: creating lockfile: 29704 fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXPort:testRead RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB1 fhs_lock: creating lockfile: 29704 fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXPort:testRead RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB0 fhs_lock: creating lockfile: 29704 fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXPort:testRead fhs_lock: creating lockfile: 29704 ... REPEATS fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXPort:testRead fhs_lock: creating lockfile: 29704 fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXCommDriver:getDeviceDirectory entering RXTXPort:testRead fhs_lock: creating lockfile: 29704 ...REPEATS fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXPort:testRead fhs_lock: creating lockfile: 29704 fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXPort:Initialize RXTX WARNING: This library was compiled to run with OS release 2.6.18 and you are currently running OS release 2.6.18-92.1.6.el5. In some cases this can be a problem. Try recompiling RXTX if you notice strange behavior. If you just compiled RXTX make sure /usr/include/linux is a symbolic link to the include files that came with the kernel source and not an older copy. press enter to continue leaving RXTXPort:Initialize entering RXTXPort:open fhs_lock: creating lockfile: 29704 open: locking worked for /dev/ttyUSB2 open: fd returned is 9 leaving RXTXPort:open entering eventLoop has_line_status_register_acess: Port does not support TIOCSERGETLSR driver_has_tiocgicount: Port does not support TIOCGICOUNT events init_threads: get eis init_threads: set eis init_threads: stop leaving RXTXPort:translate_speed entering RXTXPort:nativeSetSerialPortParams entering translate_date_bits entering translate_stop_bits leaving RXTXPort:translate_stop_bits entering translate_parity leaving translate_parity entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 ...REPEATS entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 leaving RXTXPort:nativeSetSerialPortParams entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 ...REPEATS entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 entering writeArray entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 writeArray() leaving RXTXPort:writeArray entering SerialImp.c:drain() nativeDrain: trying tcdrain RXTXPort:drain() returns: 0 leaving RXTXPort:drain() entering writeArray writeArray() leaving RXTXPort:writeArray entering SerialImp.c:drain() nativeDrain: trying tcdrain entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 Tue Apr 07 18:51:49 EDT 2009:TSerial[22]:Using Port:/dev/ttyUSB2 Tue Apr 07 18:51:49 EDT 2009:TSerial[22].Transmit:TN Tue Apr 07 18:51:49 EDT 2009:TSerial[22].Transmit:RV entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 ...REPEATS FOREVER? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090407/f26e5752/attachment-0006.html From tjarvi at qbang.org Tue Apr 7 18:31:23 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 7 Apr 2009 18:31:23 -0600 (MDT) Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: <49D546F8.20807@gatworks.com> <49D693BA.8060909@gatworks.com> Message-ID: On Tue, 7 Apr 2009, Bill Johnson wrote: > I have traced the hang down to a call to tcdrain(fd) in SerialImp.c:drain() > running and rebuilt under Netbeans on the target machine with debug messages > on. That puts it into the system code, so I'm not sure how to proceed. I > guess I could debug into the kernel source but I've not done that. I saw > some discussion about an IOCTL that sets/adjusts a timeout on tcdrain() but > that may have been for BSD. Maybe there is some new setup requirement or bug > introduced with this 2.6.18 kernel or a hardware difference. > Below is a message listing with some of the repeated parts removed. Maybe > you can see something noteworthy? > > JNI_OnLoad called. > WARNING:? RXTX Version mismatch > ??????? Jar version = RXTX-2.2pre2 > ??????? native lib Version = RXTX-2.2pre3 > entering RXTXCommDriver:getDeviceDirectory > entering RXTXPort:testRead > fhs_lock: creating lockfile:????? 29704 > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXPort:testRead > RXTX Warning:? Removing stale lock file. /var/lock/LCK..ttyUSB2 > fhs_lock: creating lockfile:????? 29704 > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXPort:testRead > RXTX Warning:? Removing stale lock file. /var/lock/LCK..ttyUSB1 > fhs_lock: creating lockfile:????? 29704 > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXPort:testRead > RXTX Warning:? Removing stale lock file. /var/lock/LCK..ttyUSB0 > fhs_lock: creating lockfile:????? 29704 > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXPort:testRead > fhs_lock: creating lockfile:????? 29704 > > ... REPEATS > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXPort:testRead > fhs_lock: creating lockfile:????? 29704 > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXCommDriver:getDeviceDirectory > entering RXTXPort:testRead > fhs_lock: creating lockfile:????? 29704 > > ...REPEATS > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXPort:testRead > fhs_lock: creating lockfile:????? 29704 > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXPort:Initialize > > > > RXTX WARNING:? This library was compiled to run with OS release 2.6.18 and > you are currently running OS release 2.6.18-92.1.6.el5.? In some cases this > can be a problem.? Try recompiling RXTX if you notice strange behavior.? If > you just compiled RXTX make sure /usr/include/linux is a symbolic link to > the include files that came with the kernel source and not an older copy. > > > press enter to continue > > leaving RXTXPort:Initialize > entering RXTXPort:open > fhs_lock: creating lockfile:????? 29704 > > open: locking worked for /dev/ttyUSB2 > open: fd returned is 9 > leaving RXTXPort:open > entering eventLoop > ? > has_line_status_register_acess: Port does not support TIOCSERGETLSR > ?driver_has_tiocgicount:? Port does not support TIOCGICOUNT events > init_threads: get eis > init_threads: set eis > init_threads:? stop > leaving RXTXPort:translate_speed > entering RXTXPort:nativeSetSerialPortParams > entering translate_date_bits > entering translate_stop_bits > leaving RXTXPort:translate_stop_bits > entering translate_parity > leaving translate_parity > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > ...REPEATS > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > leaving RXTXPort:nativeSetSerialPortParams > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > ...REPEATS > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > entering writeArray > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > writeArray() > leaving RXTXPort:writeArray > entering SerialImp.c:drain() > nativeDrain: trying tcdrain > RXTXPort:drain() returns: 0 > leaving RXTXPort:drain() > entering writeArray > writeArray() > leaving RXTXPort:writeArray > entering SerialImp.c:drain() > nativeDrain: trying tcdrain > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > Tue Apr 07 18:51:49 EDT 2009:TSerial[22]:Using Port:/dev/ttyUSB2 > Tue Apr 07 18:51:49 EDT 2009:TSerial[22].Transmit:TN > > Tue Apr 07 18:51:49 EDT 2009:TSerial[22].Transmit:RV > > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > ...REPEATS FOREVER? > > > Hi Bill ugh. The tiocmget... is the eventLoop checking for events. It sits with select() but has a timeout value to keep it spinning at a trivial rate. tcdrain() is the suspect. I don't see anything in the code that looks like a problem. If flow control is not enabled, I don't see a reason for it not to return. Given that this is USB, perhaps a message from the device got lost. Onboard UARTs would have a status register change when output buffer is empty. USB needs to communicate the event as an HID device which may be the source of the error. Dropping back to onboard UARTs eliminates that portion of the mix. What vendor/chipset is the USB dongle? I understand code has been pushed upon the linux serial devices for new for things like acpi. There very well could be a bug introduced. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Apr 7 18:38:22 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 7 Apr 2009 18:38:22 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49DB4212.40807@bbs.darktech.org> References: <49DB4212.40807@bbs.darktech.org> Message-ID: On Tue, 7 Apr 2009, cowwoc wrote: >> just two minor details, first about the errno change, I though >> >> #include >> extern int errno; >> >> is correct (POSIX.1) - why this change? > > If you compile this under Visual Studio 2008 you will get warnings that > the errno type being imported is different from the type being exported. > The definition I pasted is the one being exported. Perhaps we should use > #ifdef WIN32 for this? > Hi Gili, Perhaps a workaround for _MSVC is in order. GNU compilers for windows won't complain. If it's a question of MSVC or POSIX being right, the library favors the standard as a stated goal. I'm not sure what MSVC is using errno for but it should not be using it except with POSIX extensions. Perhaps #undef is enough to get rid of the warning and (maybe) has no ill consequences. Newer windows have POSIX extensions that may show how Microsoft solved the problem. It can probably fester. -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Tue Apr 7 19:54:06 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Tue, 07 Apr 2009 21:54:06 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: References: <49DB4212.40807@bbs.darktech.org> Message-ID: <49DC03BE.5010203@bbs.darktech.org> Trent Jarvi wrote: > I'm not sure what MSVC is using errno for but it should not be using it > except with POSIX extensions. Perhaps #undef is enough to get rid of > the warning and (maybe) has no ill consequences. Newer windows have > POSIX extensions that may show how Microsoft solved the problem. > > It can probably fester. What does "newer windows" refer to in this case? I was compiling using Visual Studio 2008 sp1 under Windows Vista. Both are cutting edge technologies as far as official releases go. I think you're best suited to judge whether this warning is a big deal or not so I think you should see it for yourself. Please try firing up Visual Studio 2008 (express?) against the project I sent you. Gili From Steffen.DETTMER at ingenico.com Wed Apr 8 05:50:42 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 8 Apr 2009 13:50:42 +0200 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49DC03BE.5010203@bbs.darktech.org> References: <49DB4212.40807@bbs.darktech.org> <49DC03BE.5010203@bbs.darktech.org> Message-ID: <20090408115042.GC5090@elberon.bln.de.ingenico.com> * cowwoc wrote on Tue, Apr 07, 2009 at 21:54 -0400: > Trent Jarvi wrote: > > I'm not sure what MSVC is using errno for but it should not be using it > > except with POSIX extensions. Perhaps #undef is enough to get rid of > > the warning and (maybe) has no ill consequences. Newer windows have > > POSIX extensions that may show how Microsoft solved the problem. I think here best is simply to omit this old^Wclassic `extern int errno;' line completely. I think standards just say something like `implementations may support the declaration extern int errno;'. About POSIX extensions I think in general it should be considered that althrough many things are available, even with MS Visual C++, the Microsoft tools lead developers to write non-portable code (and personally I think this is intentional). For example, they call the official ISO-C function `strerror' deprecated (!) and twaddle about some security enhancements (without even beeing specific). Someone could, because of this, lead to use the MS specific, unportable `strerror_s' instead. Even better, at _strerror_s they tell, for `ANSI compatiblity someone should use strerror_s'. Of course a program using [_]strerror_s won't be ANSI-C compliant. Do they mean strerror_r? _strerror_s has the same parameters - but of course in different order - to make porting a pain... SCNR. > What does "newer windows" refer to in this case? I was compiling using > Visual Studio 2008 sp1 under Windows Vista. Both are cutting edge > technologies as far as official releases go. `cutting edge technologies' yeah post-standard, portability-cutting technologies smoothing the way to MS world domination; own post-ANSI-C programming languages help (maybe to increase the share holder value)... SCNR. > I think you're best suited to judge whether this warning is a big deal > or not so I think you should see it for yourself. Please try firing up > Visual Studio 2008 (express?) against the project I sent you. yeah, getting the CL.EXE of 2008 running in a normal command line environment (without its special `C++ Shell') is a bit tricky - but possible. ;) oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From tjarvi at qbang.org Wed Apr 8 14:29:54 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 8 Apr 2009 14:29:54 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49DC03BE.5010203@bbs.darktech.org> References: <49DB4212.40807@bbs.darktech.org> <49DC03BE.5010203@bbs.darktech.org> Message-ID: The support has been around for a long time to. I don't know the details but the support appears to be tied to the OS. http://en.wikipedia.org/wiki/POSIX#POSIX_for_Windows On Tue, 7 Apr 2009, cowwoc wrote: > Trent Jarvi wrote: >> I'm not sure what MSVC is using errno for but it should not be using it >> except with POSIX extensions. Perhaps #undef is enough to get rid of the >> warning and (maybe) has no ill consequences. Newer windows have POSIX >> extensions that may show how Microsoft solved the problem. >> >> It can probably fester. > > What does "newer windows" refer to in this case? I was compiling > using Visual Studio 2008 sp1 under Windows Vista. Both are cutting edge > technologies as far as official releases go. > > I think you're best suited to judge whether this warning is a big > deal or not so I think you should see it for yourself. Please try firing up > Visual Studio 2008 (express?) against the project I sent you. > > Gili > From bill7007 at gmail.com Wed Apr 8 15:59:08 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Wed, 8 Apr 2009 17:59:08 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: <49D546F8.20807@gatworks.com> <49D693BA.8060909@gatworks.com> Message-ID: Hi Trent, I think I have hit on a work around but don't know why it works. The USB serial adapter is a "CableMAX" based on Prolific's PL2303. Backing out to the big picture, the application is old and has been very reliable until put on a new cpu and kernel. It only hangs sometimes say 25% and always at the same place, at tcdrain() on the flush() after the second write after startup. If it made it past this stage, all transmit and receive seemed reliable so it was like a startup timing issue. Since learning to debug kernel code is beyond my immediate priority, I took a shot at moving code around, adding delays, and such. I have found it good practice to do a flush after every write on streams like: outputStream.write(data.getBytes()); outputStream.flush(); If I remove the flush() after each write, the problem appears to go away! I don't think the flush is needed for a SerialOutputStream for this application anyway. Thanks for all the help, +BillJ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090408/35d96a9d/attachment-0004.html From bill7007 at gmail.com Thu Apr 9 09:20:11 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Thu, 9 Apr 2009 11:20:11 -0400 Subject: [Rxtx] Baud rate fixes in 2.2pre2 breaks 38400 on some Linux devices Message-ID: Hello, An application that worked at 38400 on a USB serial adapter (PL2303) using 2.1-7-r2 on Linux EL4 (and EL5) now fails using 2.2pre2. serialPort.setSerialPortParams(38400,SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); throws an unsupportedCommOperationException This problem matched a description of Bug 113and I posted a proposed patch there, but I don't understand the whole custom baud rate patch so it may need some thought. An older patch, [Rxtx] [Patch]: Baud Rate fixes try 1, testing encouraged., fixed some custom baud rates but apparently broke 38400 on some Linux device. Other baud rates seem to work OK. And, 38400 tested OK on local non-USB ports. My proposed patch probably breaks the custom baud rate patch since it was keyed on 38400 as a special case for Linux and my fix was to back out part of that patch, specifically: #if defined(TIOCGSERIAL) if ( cspeed == B38400 ) cspeed = 38400; #endif /* TIOCGSERIAL */ +BillJ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090409/5636af64/attachment-0003.html From cowwoc at bbs.darktech.org Fri Apr 10 08:38:49 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Fri, 10 Apr 2009 10:38:49 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: References: <49DB4212.40807@bbs.darktech.org> <49DC03BE.5010203@bbs.darktech.org> Message-ID: <49DF59F9.2050408@bbs.darktech.org> Doesn't Wikipedia list as an optional sub-system? Gili Trent Jarvi wrote: > > The support has been around for a long time to. I don't know the > details but the support appears to be tied to the OS. > > http://en.wikipedia.org/wiki/POSIX#POSIX_for_Windows > > On Tue, 7 Apr 2009, cowwoc wrote: > >> Trent Jarvi wrote: >>> I'm not sure what MSVC is using errno for but it should not be using >>> it except with POSIX extensions. Perhaps #undef is enough to get >>> rid of the warning and (maybe) has no ill consequences. Newer >>> windows have POSIX extensions that may show how Microsoft solved the >>> problem. >>> >>> It can probably fester. >> >> What does "newer windows" refer to in this case? I was compiling >> using Visual Studio 2008 sp1 under Windows Vista. Both are cutting >> edge technologies as far as official releases go. >> >> I think you're best suited to judge whether this warning is a big >> deal or not so I think you should see it for yourself. Please try >> firing up Visual Studio 2008 (express?) against the project I sent you. >> >> Gili >> From eranshuman at gmail.com Mon Apr 13 04:50:34 2009 From: eranshuman at gmail.com (Anshuman Srivastava) Date: Mon, 13 Apr 2009 16:20:34 +0530 Subject: [Rxtx] Send RTS /DTR signal Message-ID: <589913a50904130350n59cc51ffvbcd0a4eaefb4ce5f@mail.gmail.com> Hi, I want to send the RTS or DTR signal from the application Can anybody telll how to send the DTR /RTS signal using rxtxcomm libraries Thanks and regards -- Anshuman Srivastava "... in the end, it's not the years in your life that count. It's the life in your years." Buzz +91 9962515155 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090413/211b5ded/attachment.html From cowwoc at bbs.darktech.org Wed Apr 1 22:05:13 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Thu, 02 Apr 2009 00:05:13 -0400 Subject: [Rxtx] Windows 64-bit support? Message-ID: <49D43979.4050702@bbs.darktech.org> Hi, I'd like to run RXTX under the Windows 64-bit JVM. Are there plans to release an official 64-bit version anytime soon? Gili From bill7007 at gmail.com Thu Apr 2 16:01:17 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Thu, 2 Apr 2009 18:01:17 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel Message-ID: Hi, I have an rxtx serial application that used to work reliably until I had to move it to newer hardware and kernel. Now, the application sometimes hangs near first port use. When it does hang, it can be released by starting a second copy of the application which is locked out of the ports but does release the first process. Upgraded from rxtx-2.1-7-r2 to rxtx-2.2pre2 but still hangs. Tried to rebuild on the target machine and ran into the 'UTS_RELEASE' undeclared problem so holding on that approach. Recompiled OK on a 2.6.9-42.0.3.ELsmp system. Debug messages were turned on using: "./configure --enable-DEBUG" and modified RXTXPort.java with: "debug = true;" "z = new Zystem(Zystem.PRINT_MODE);" Below is capture of the application with debugging enabled. It show the application hang point, and the second application's printout at the release point. (pre3 is the locally modified version of pre2) Any suggestions on how to pin this down further? Thanks, +BillJ $ java -version java version "1.5.0_06" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05) Java HotSpot(TM) Client VM (build 1.5.0_06-b05, mixed mode, sharing) $ uname -a Linux qms4 2.6.18-92.1.6.el5 #1 SMP Wed Jun 25 13:49:24 EDT 2008 i686 i686 i386 GNU/Linux ***CAPTURE: [qms at qms4 ~]$ ./qms/ScriptFiles/startup.sh Thu Apr 02 13:35:45 EDT 2009:Setting Log File to:/home/qms/qms/QMS.log Thu Apr 02 13:35:45 EDT 2009:TSettings.HandleIni:ReUsing Ini file:/home/qms/qms/qms.properties WARNING: RXTX Version mismatch Jar version = RXTX-2.2pre2 native lib Version = RXTX-2.2pre3 fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB2 fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB1 fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB0 fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile RXTXPort {} RXTX WARNING: This library was compiled to run with OS release 2.4.20 and you are currently running OS release 2.6.18-92.1.6.el5. In some cases this can be a problem. Try recompiling RXTX if you notice strange behavior. If you just compiled RXTX make sure /usr/include/linux is a symbolic link to the include files that came with the kernel source and not an older copy. press enter to continue RXTXPort:RXTXPort(/dev/ttyUSB2) called fhs_lock: creating lockfile: 10127 open: locking worked for /dev/ttyUSB2 open: fd returned is 8 RXTXPort:MontitorThread:MonitorThread() RXTXPort:MontitorThread:run() has_line_status_register_acess: Port does not support TIOCSERGETLSR init_threads: get eis init_threads: set eis init_threads: stop RXTXPort:RXTXPort(/dev/ttyUSB2) returns with fd = 8 RXTXPort:setSerialPortParams(38400 8 1 0) called RXTXPort:setSerialPortParams(38400 8 1 0) returning RXTXPort:getInputStream() called and returning Thu Apr 02 13:36:02 EDT 2009:TSerial[22]:Using Port:/dev/ttyUSB2 RXTXPort:getOutputStream() called and returning Thu Apr 02 13:36:02 EDT 2009:TSerial[22].Transmit:TN Entering RXTXPort:SerialOutputStream:write(4) writeArray() Leaving RXTXPort:SerialOutputStream:write(4) RXTXPort:SerialOutputStream:flush() enter RXTXPort:SerialOutputStream:flush() leave Thu Apr 02 13:36:02 EDT 2009:TSerial[22].Transmit:RV Entering RXTXPort:SerialOutputStream:write(4) writeArray() Leaving RXTXPort:SerialOutputStream:write(4) RXTXPort:SerialOutputStream:flush() enter RXTXPort:SerialInputStream:read(8192 0 8192) called ***FIRST PROCESS HANGS HERE ***THEN PROCEEDS AFTER SECOND PROCESS STARTS RXTXPort:SerialOutputStream:flush() leave Thu Apr 02 13:41:29 EDT 2009:TSerial[22].Transmit:IH9 Entering RXTXPort:SerialOutputStream:write(5) writeArray() Leaving RXTXPort:SerialOutputStream:write(5) RXTXPort:SerialOutputStream:flush() enter RXTXPort:SerialOutputStream:flush() leave Thu Apr 02 13:41:29 EDT 2009:TSerial[22].Transmit:IL11 ***END CAPTURE ***CAPTURE SECOND PROCESS FAILS OPEN [qms at qms4 ~]$ ./qms/ScriptFiles/startup.sh Thu Apr 02 13:41:27 EDT 2009:Setting Log File to:/home/qms/qms/QMS.log Thu Apr 02 13:41:27 EDT 2009:TSettings.HandleIni:ReUsing Ini file:/home/qms/qms/qms.properties WARNING: RXTX Version mismatch Jar version = RXTX-2.2pre2 native lib Version = RXTX-2.2pre3 fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB2: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB1: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB0: File exists fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB2: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB1: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB0: File exists fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile Thu Apr 02 13:41:30 EDT 2009:TIOBoard: java.io.IOException: java.io.IOException: TSerial[22]: Open Failed ***END CAPTURE -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090402/c66f8d70/attachment-0012.html From netbeans at gatworks.com Thu Apr 2 17:15:04 2009 From: netbeans at gatworks.com (U. George) Date: Thu, 02 Apr 2009 19:15:04 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: Message-ID: <49D546F8.20807@gatworks.com> > "z = new Zystem(Zystem.PRINT_MODE);" > Below is capture of the application with debugging enabled. It show > the application hang point, and the second application's printout at the > release point. (pre3 is the locally modified version of pre2) > Any suggestions on how to pin this down further? > Thanks, > +BillJ When perceived runability is hung, try a ^\ ( control \) on console. This gets the JVM to dump the stacks of all the java threads. If you know the thread that is stuck, then u can see what java statement its stuck at. From tjarvi at qbang.org Thu Apr 2 19:25:17 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 2 Apr 2009 19:25:17 -0600 (MDT) Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: <49D546F8.20807@gatworks.com> References: <49D546F8.20807@gatworks.com> Message-ID: On Thu, 2 Apr 2009, U. George wrote: >> "z = new Zystem(Zystem.PRINT_MODE);" >> Below is capture of the application with debugging enabled. It show >> the application hang point, and the second application's printout at the >> release point. (pre3 is the locally modified version of pre2) >> Any suggestions on how to pin this down further? >> Thanks, >> +BillJ > > When perceived runability is hung, try a ^\ ( control \) on console. > This gets the JVM to dump the stacks of all the java threads. > If you know the thread that is stuck, then u can see what java statement > its stuck at. I've also noticed some linux systems hanging with open/read/write and saw kacpid storms. I need to look at it more but did observe kacpid consuming a core and not returning to a normal state for a significant period of time. It was easy to observe from top sorted by CPU usage. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Apr 2 19:26:18 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 2 Apr 2009 19:26:18 -0600 (MDT) Subject: [Rxtx] Windows 64-bit support? In-Reply-To: <49D43979.4050702@bbs.darktech.org> References: <49D43979.4050702@bbs.darktech.org> Message-ID: On Thu, 2 Apr 2009, cowwoc wrote: > Hi, > > I'd like to run RXTX under the Windows 64-bit JVM. Are there plans > to release an official 64-bit version anytime soon? > It is in the prerelease and will be in the final release. I'm pushing it through as fast as I can in my free time. -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Thu Apr 2 22:57:34 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Fri, 03 Apr 2009 00:57:34 -0400 Subject: [Rxtx] Missing documentation In-Reply-To: References: <49D43979.4050702@bbs.darktech.org> Message-ID: <49D5973E.4050400@bbs.darktech.org> Hi, I noticed that RXTX 2.1 drops javax.comm support in favor of gnu.io. I have one major problem with this: the gui.io.* documentation is very poor. Many classes and methods have no Javadoc at all which makes them difficult to use. Please fix this for the final release. Thank you, Gili From alex.sas at freemail.hu Fri Apr 3 01:36:54 2009 From: alex.sas at freemail.hu (Sas Alex) Date: Fri, 3 Apr 2009 09:36:54 +0200 (CEST) Subject: [Rxtx] Serial port false reads Message-ID: Hi all, On Windows XP, using rxtx-2.1-7-r2 I have a program communicating on a serial line like the following (excerpt): { os.write(command); os.flush(); // Thread.sleep(period); // read response while(is.available() > 0) { is.read() } } If there is a sleep between the os.flush and the reading cycle the correct answer is received. Otherwise (sometimes) there are extra, erronous characters at the beginning of the answer, but the correct answer (according to the protocol) also arrives, afterwards. Is this a normal behaviour, one should wait before the read? If yes, is there a way to determine the minimum amount of time to wait for? Serial port params are: 9600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE. Thank you in advance, Alex ________________________________________________________ El?foglal?si akci? meghosszabb?tva! Korfui ?d?l?s m?r 56.910 Ft-t?l. http://www.budavartours.hu/gorogorszag/?utm_campaign=origo&utm_source=freemail_kimeno_090403&utm_medium=ct&utm_content=korfu_elofoglalasi_akcio#reg_Korfu -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090403/8f3650ea/attachment-0012.html From bill7007 at gmail.com Fri Apr 3 16:15:30 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Fri, 3 Apr 2009 18:15:30 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: <49D546F8.20807@gatworks.com> Message-ID: > When perceived runability is hung, try a ^\ ( control \) on console. >> This gets the JVM to dump the stacks of all the java threads. > > Good idea... A thread dump is below, it looks like only some system threads are in wait state which is probably normal. The "main" thread is stopped writing the first data out the serial port which should complete but its has stopped at: at gnu.io.RXTXPort.nativeDrain(Native Method) It show its state as runnable though. There is another thread, "SerialReader_22", that is waiting to read any data on the same port. I'll bring the app up under Netbeans debugger next. >> > I've also noticed some linux systems hanging with open/read/write and saw > kacpid storms. No CPU use going when it hangs, acts like a deadlock. THREAD DUMP AT HANG: Entering RXTXPort:SerialOutputStream:write(4) writeArray() Leaving RXTXPort:SerialOutputStream:write(4) RXTXPort:SerialOutputStream:flush() enter RXTXPort:SerialInputStream:read(8192 0 8192) called Full thread dump Java HotSpot(TM) Client VM (1.5.0_06-b05 mixed mode, sharing): "SerialReader_22" daemon prio=1 tid=0x087abf38 nid=0x3c8b runnable [0xb1a43000..0xb1a43f30] at gnu.io.RXTXPort.readArray(Native Method) at gnu.io.RXTXPort$SerialInputStream.read(RXTXPort.java:1454) - locked <0x88ca55b8> (a gnu.io.RXTXPort$SerialInputStream) at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:411) at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) - locked <0x88cab378> (a java.io.InputStreamReader) at java.io.InputStreamReader.read(InputStreamReader.java:167) at java.io.BufferedReader.fill(BufferedReader.java:136) at java.io.BufferedReader.readLine(BufferedReader.java:299) - locked <0x88cab378> (a java.io.InputStreamReader) at java.io.BufferedReader.readLine(BufferedReader.java:362) at qms.TSerialPort$SerialRead.run(TSerialPort.java:268) at java.lang.Thread.run(Thread.java:595) "Thread-1" prio=1 tid=0x08a43360 nid=0x3c8a runnable [0xb1ac4000..0xb1ac4db0] at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1641) "AWT-XAWT" daemon prio=1 tid=0x08acc848 nid=0x3c87 runnable [0xb1b45000..0xb1b45e30] at sun.awt.X11.XToolkit.waitForEvents(Native Method) at sun.awt.X11.XToolkit.run(XToolkit.java:463) at sun.awt.X11.XToolkit.run(XToolkit.java:438) at java.lang.Thread.run(Thread.java:595) "Java2D Disposer" daemon prio=1 tid=0x08ab9d30 nid=0x3c86 in Object.wait() [0xb1bc6000..0xb1bc70b0] at java.lang.Object.wait(Native Method) - waiting on <0x8917b110> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:116) - locked <0x8917b110> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:132) at sun.java2d.Disposer.run(Disposer.java:107) at java.lang.Thread.run(Thread.java:595) "Low Memory Detector" daemon prio=1 tid=0x087bea68 nid=0x3c84 runnable [0x00000000..0x00000000] "CompilerThread0" daemon prio=1 tid=0x087bd4c0 nid=0x3c83 waiting on condition [0x00000000..0xb23a7a18] "Signal Dispatcher" daemon prio=1 tid=0x087bc520 nid=0x3c82 runnable [0x00000000..0x00000000] "Finalizer" daemon prio=1 tid=0x087b5710 nid=0x3c81 in Object.wait() [0xb26a9000..0xb26a9f30] at java.lang.Object.wait(Native Method) - waiting on <0x8914a770> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:116) - locked <0x8914a770> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:132) at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159) "Reference Handler" daemon prio=1 tid=0x087b49c8 nid=0x3c80 in Object.wait() [0xb272a000..0xb272adb0] at java.lang.Object.wait(Native Method) - waiting on <0x8914a7f0> (a java.lang.ref.Reference$Lock) at java.lang.Object.wait(Object.java:474) at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116) - locked <0x8914a7f0> (a java.lang.ref.Reference$Lock) "main" prio=1 tid=0x08777b88 nid=0x3c7e runnable [0xbffa7000..0xbffa74f8] at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1248) at qms.TSerialPort.Transmit(TSerialPort.java:192) - locked <0x88c99a68> (a qms.TSerialPort) at qms.TIOBoard.GetIOBoardVersion(TIOBoard.java:168) at qms.TIOBoard.(TIOBoard.java:73) at qms.TQMS.(TQMS.java:47) at qms.MainForm.(MainForm.java:2076) at qms.MainForm.main(MainForm.java:2099) "VM Thread" prio=1 tid=0x087b1e20 nid=0x3c7f runnable "VM Periodic Task Thread" prio=1 tid=0x087bff50 nid=0x3c85 waiting on condition -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090403/20b7bca4/attachment-0011.html From Martin.Oberhuber at windriver.com Fri Apr 3 16:23:43 2009 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Sat, 4 Apr 2009 00:23:43 +0200 Subject: [Rxtx] Missing documentation In-Reply-To: <49D5973E.4050400@bbs.darktech.org> References: <49D43979.4050702@bbs.darktech.org> <49D5973E.4050400@bbs.darktech.org> Message-ID: <460801A4097E3D4CA04CC64EE648584809C8BD6F@ism-mail03.corp.ad.wrs.com> Hello Gili, The classes in the gnu.io namespace are designed to work exactly as their counterparts in the javax.comm namespace. Therefore, if you just take the javax.comm Javadocs that's what you want. Unfortunately I don't think we can just copy & paste the javax.comm Javadocs into RXTX due to license restrictions. I guess that's the main reason why RXTX is not (yet) Javadoc'd as extensively as it should be. Actually, writing Javadocs from scratch WITHOUT referencing the wording of the Sun Javadocs is not that easy. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of cowwoc > Sent: Freitag, 03. April 2009 06:58 > To: rxtx at qbang.org > Subject: [Rxtx] Missing documentation > > Hi, > > I noticed that RXTX 2.1 drops javax.comm support in favor > of gnu.io. > I have one major problem with this: the gui.io.* > documentation is very > poor. Many classes and methods have no Javadoc at all which > makes them > difficult to use. Please fix this for the final release. > > Thank you, > Gili > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Fri Apr 3 16:54:50 2009 From: netbeans at gatworks.com (U. George) Date: Fri, 03 Apr 2009 18:54:50 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: <49D546F8.20807@gatworks.com> Message-ID: <49D693BA.8060909@gatworks.com> I would have tried 2 or 3 "^\" . If things are stuck, then all will be at same 'java' instruction. If thread is moving, then one of the snapshots would be different. I *think* flushing/draining wont return until the kernel buffers to device have been accepted by device. Stuck/paused device? Bill Johnson wrote: > > > > > When perceived runability is hung, try a ^\ ( control \) on console. > This gets the JVM to dump the stacks of all the java threads. > > > Good idea... A thread dump is below, it looks like only some system > threads are in wait state which is prob From cowwoc at bbs.darktech.org Fri Apr 3 17:45:09 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Fri, 03 Apr 2009 19:45:09 -0400 Subject: [Rxtx] Missing documentation In-Reply-To: <460801A4097E3D4CA04CC64EE648584809C8BD6F@ism-mail03.corp.ad.wrs.com> References: <49D43979.4050702@bbs.darktech.org> <49D5973E.4050400@bbs.darktech.org> <460801A4097E3D4CA04CC64EE648584809C8BD6F@ism-mail03.corp.ad.wrs.com> Message-ID: <49D69F85.3030804@bbs.darktech.org> You could always send Sun a formal email and ask for permission to copy their Javadoc. I doubt they would give you problems. Gili Oberhuber, Martin wrote: > Hello Gili, > > The classes in the gnu.io namespace are designed to work exactly > as their counterparts in the javax.comm namespace. Therefore, > if you just take the javax.comm Javadocs that's what you want. > > Unfortunately I don't think we can just copy & paste the > javax.comm Javadocs into RXTX due to license restrictions. > > I guess that's the main reason why RXTX is not (yet) Javadoc'd > as extensively as it should be. Actually, writing Javadocs > from scratch WITHOUT referencing the wording of the Sun > Javadocs is not that easy. > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] >> On Behalf Of cowwoc >> Sent: Freitag, 03. April 2009 06:58 >> To: rxtx at qbang.org >> Subject: [Rxtx] Missing documentation >> >> Hi, >> >> I noticed that RXTX 2.1 drops javax.comm support in favor >> of gnu.io. >> I have one major problem with this: the gui.io.* >> documentation is very >> poor. Many classes and methods have no Javadoc at all which >> makes them >> difficult to use. Please fix this for the final release. >> >> Thank you, >> Gili >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> From cowwoc at bbs.darktech.org Sat Apr 4 15:13:38 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sat, 04 Apr 2009 17:13:38 -0400 Subject: [Rxtx] Java5 support Message-ID: <49D7CD82.1040904@bbs.darktech.org> Now that you dropped javax.comm support, how about improving the API by replacing Enumation by Iterator, int by enum, and using Generics? It would improve the usability of the API. Gili From cowwoc at bbs.darktech.org Sat Apr 4 16:12:13 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sat, 04 Apr 2009 18:12:13 -0400 Subject: [Rxtx] RXTX Version mismatch in 2.2pre2 Message-ID: <49D7DB3D.5040008@bbs.darktech.org> When using RXTX-2.2pre2 I always get the following message: WARNING: RXTX Version mismatch Jar version = RXTX-2.2pre1 native lib Version = RXTX-2.2pre2 I have double checked that I am using the correct Jar file. Is this a known bug in pre2? Gili From tjarvi at qbang.org Sat Apr 4 16:48:53 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Apr 2009 16:48:53 -0600 (MDT) Subject: [Rxtx] RXTX Version mismatch in 2.2pre2 In-Reply-To: <49D7DB3D.5040008@bbs.darktech.org> References: <49D7DB3D.5040008@bbs.darktech.org> Message-ID: > When using RXTX-2.2pre2 I always get the following message: > > WARNING: RXTX Version mismatch > Jar version = RXTX-2.2pre1 > native lib Version = RXTX-2.2pre2 > Yep. You should still be able to test it. -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Sat Apr 4 16:50:43 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sat, 04 Apr 2009 18:50:43 -0400 Subject: [Rxtx] RXTX Version mismatch in 2.2pre2 In-Reply-To: References: <49D7DB3D.5040008@bbs.darktech.org> Message-ID: <49D7E443.9070404@bbs.darktech.org> In other words this is a known bug that will be fixed in the final version? Gili Trent Jarvi wrote: > > >> When using RXTX-2.2pre2 I always get the following message: >> >> WARNING: RXTX Version mismatch >> Jar version = RXTX-2.2pre1 >> native lib Version = RXTX-2.2pre2 >> > > Yep. > > You should still be able to test it. > > -- > Trent Jarvi > tjarvi at qbang.org From cowwoc at bbs.darktech.org Sat Apr 4 16:57:34 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sat, 04 Apr 2009 18:57:34 -0400 Subject: [Rxtx] IOException: Underlying input stream returned zero bytes Message-ID: <49D7E5DE.2050405@bbs.darktech.org> Hi, There seems to be a bug in RXTX 2.2pre2's handling of InputStream timeouts. If you open a serial port without ever invoking enableReceiveTimeout() then invoking InputStream.read() will always return 0 bytes right away. If you wrap the InputStream and invoke BufferedReader.readline() you will get the following exception: java.io.IOException: Underlying input stream returned zero bytes at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:268) [na:1.6.0_14-ea] at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:306) [na:1.6.0_14-ea] at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:158) [na:1.6.0_14-ea] at java.io.InputStreamReader.read(InputStreamReader.java:167) [na:1.6.0_14-ea] at java.io.BufferedReader.fill(BufferedReader.java:136) [na:1.6.0_14-ea] at java.io.BufferedReader.readLine(BufferedReader.java:299) [na:1.6.0_14-ea] at java.io.BufferedReader.readLine(BufferedReader.java:362) [na:1.6.0_14-ea] [snip] If you enable a timeout, the exception will only occur after the timeout expires. In short, it looks like RXTX is using a default timeout of zero (I am expecting it to block forever). It looks like other people have run into this as well: http://forums.sun.com/thread.jspa?threadID=5165346&start=10&tstart=0 Please confirm whether this is a known bug. Thank you, Gili From tjarvi at qbang.org Sat Apr 4 17:27:19 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Apr 2009 17:27:19 -0600 (MDT) Subject: [Rxtx] IOException: Underlying input stream returned zero bytes In-Reply-To: <49D7E5DE.2050405@bbs.darktech.org> References: <49D7E5DE.2050405@bbs.darktech.org> Message-ID: On Sat, 4 Apr 2009, cowwoc wrote: > Hi, > > There seems to be a bug in RXTX 2.2pre2's handling of InputStream > timeouts. If you open a serial port without ever invoking > enableReceiveTimeout() then invoking InputStream.read() will always > return 0 bytes right away. If you wrap the InputStream and invoke > BufferedReader.readline() you will get the following exception: > > java.io.IOException: Underlying input stream returned zero bytes > at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:268) > [na:1.6.0_14-ea] > at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:306) > [na:1.6.0_14-ea] > at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:158) > [na:1.6.0_14-ea] > at java.io.InputStreamReader.read(InputStreamReader.java:167) > [na:1.6.0_14-ea] > at java.io.BufferedReader.fill(BufferedReader.java:136) > [na:1.6.0_14-ea] > at java.io.BufferedReader.readLine(BufferedReader.java:299) > [na:1.6.0_14-ea] > at java.io.BufferedReader.readLine(BufferedReader.java:362) > [na:1.6.0_14-ea] > [snip] > > If you enable a timeout, the exception will only occur after the > timeout expires. In short, it looks like RXTX is using a default timeout > of zero (I am expecting it to block forever). It looks like other people > have run into this as well: > http://forums.sun.com/thread.jspa?threadID=5165346&start=10&tstart=0 > > Please confirm whether this is a known bug. > Hi Gili I've known about it but was not sure if it was a bug or not. It looks like we can treat it as a bug if nio is throwing an exception. Timeout and Thresholds are well documented in javax.comm but I didn't recall seeing defaults. For that reason, I've encouraged people to set the threshold and timeout to what they expect. Another note about InputStream.read(void): I noticed that I don't use that function at all while looking at code coverage results. Keep your eye out for additional issues. -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Sat Apr 4 19:03:29 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sat, 04 Apr 2009 21:03:29 -0400 Subject: [Rxtx] IOException: Underlying input stream returned zero bytes In-Reply-To: References: <49D7E5DE.2050405@bbs.darktech.org> Message-ID: <49D80361.7020801@bbs.darktech.org> Trent Jarvi wrote: > For that reason, I've encouraged people to set the threshold and timeout > to what they expect. It doesn't help. There doesn't seem to be a way to disable the timeout, even if you invoke disableReceiveTimeout() explicitly. Let me know when you put in a fix and I will test it. Thanks, Gili From cowwoc at bbs.darktech.org Sat Apr 4 23:27:25 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 01:27:25 -0400 Subject: [Rxtx] Crash in termios.c:892 Message-ID: <49D8413D.7040105@bbs.darktech.org> I can reproduce a crash in RXTX 2.2 pre2 100% of the time using my application code, but I can't seem to bring it down to a minimal testcase. Here is what I see: - thread begins running - open com1 - close com1 - open com5 - leave com5 open - thread shuts down - repeat the same process in a new thread - crash occurs when trying to open com1. Crash disappears if I close() com5 in the previous thread. The output window contains the following: # # A fatal error has been detected by the Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x05475cf6, pid=6064, tid=5436 # # JRE version: 6.0_14-b04 # Java VM: Java HotSpot(TM) Client VM (14.0-b13 mixed mode, sharing windows-x86 ) # Problematic frame: # C [rxtxSerial.dll+0x5cf6] # # An error report file with more information is saved as: # C:\Users\Gili\Documents\foobar\source\hs_err_pid6064.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp Error 0x5 at ..\src\termios.c(892): Access is denied. # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # Please let me know if the crash dump is enough to track down this bug. Thank you, Gili -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: hs_err_pid6064.log Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20090405/7133a1ce/attachment-0008.pl From cowwoc at bbs.darktech.org Sun Apr 5 00:24:19 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 02:24:19 -0400 Subject: [Rxtx] SerialPort.getName() is wrong Message-ID: <49D84E93.7050606@bbs.darktech.org> Sorry for all these emails but I keep on running into more issues. Here is what I noticed: - CommPortIdentifier.getPortIdentifier("COM5") returns a CommPortIdentifier where getName() == "COM5" - If, however, you invoke CommPortIdentifier.open() you get back a SerialPort where SerialPort.getName() is "//./COM5" I am expecting the name to remain consistent. "//./COM5" looks like an implementation detail and (as far as I can tell) it can't be used as an argument for any API method so it is somewhat useless. If getName() were to return "COM5" I could at least use it to get back the original CommPortIdentifier or compare against "known names" such as "COMx" or "LPTx". What do you think? Gili From tjarvi at qbang.org Sun Apr 5 10:18:42 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Apr 2009 10:18:42 -0600 (MDT) Subject: [Rxtx] SerialPort.getName() is wrong In-Reply-To: <49D84E93.7050606@bbs.darktech.org> References: <49D84E93.7050606@bbs.darktech.org> Message-ID: On Sun, 5 Apr 2009, cowwoc wrote: > > Sorry for all these emails but I keep on running into more issues. > Here is what I noticed: > > - CommPortIdentifier.getPortIdentifier("COM5") returns a > CommPortIdentifier where getName() == "COM5" > - If, however, you invoke CommPortIdentifier.open() you get back a > SerialPort where SerialPort.getName() is "//./COM5" > > I am expecting the name to remain consistent. "//./COM5" looks like > an implementation detail and (as far as I can tell) it can't be used as > an argument for any API method so it is somewhat useless. If getName() > were to return "COM5" I could at least use it to get back the original > CommPortIdentifier or compare against "known names" such as "COMx" or > "LPTx". What do you think? > Sure. If it itches enough you should be able to fix this in RXTXCommDriver.java. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Apr 5 10:27:58 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Apr 2009 10:27:58 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D8413D.7040105@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> Message-ID: On Sun, 5 Apr 2009, cowwoc wrote: > > I can reproduce a crash in RXTX 2.2 pre2 100% of the time using my > application code, but I can't seem to bring it down to a minimal testcase. > Here is what I see: > > - thread begins running > - open com1 > - close com1 > - open com5 > - leave com5 open > - thread shuts down > - repeat the same process in a new thread > - crash occurs when trying to open com1. Crash disappears if I close() com5 > in the previous thread. > > The output window contains the following: > > # > # A fatal error has been detected by the Java Runtime Environment: > # > # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x05475cf6, pid=6064, > tid=5436 > # > # JRE version: 6.0_14-b04 > # Java VM: Java HotSpot(TM) Client VM (14.0-b13 mixed mode, sharing > windows-x86 ) > # Problematic frame: > # C [rxtxSerial.dll+0x5cf6] > # > # An error report file with more information is saved as: > # C:\Users\Gili\Documents\foobar\source\hs_err_pid6064.log > # > # If you would like to submit a bug report, please visit: > # http://java.sun.com/webapps/bugreport/crash.jsp > Error 0x5 at ..\src\termios.c(892): Access is denied. > > > # The crash happened outside the Java Virtual Machine in native code. > # See problematic frame for where to report the bug. > # > > Please let me know if the crash dump is enough to track down this bug. > Hi Gili, You are responsible for cleaning up the serial ports when using threads. That said, if the thread did shut down, finalize should have been called if you are not passing the object around. See RXTXPort.java. protected void finalize() { if (debug) z.reportln( "RXTXPort:finalize()"); if( fd > 0 ) { if (debug) z.reportln( "RXTXPort:calling close()"); close(); } z.finalize(); } The exception is interesting. This is on Vista? Usually it just gives an open error when another process has the port. -- Trent Jarvi tjarvi at mathworks.com From cowwoc at bbs.darktech.org Sun Apr 5 10:35:55 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 12:35:55 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: References: <49D8413D.7040105@bbs.darktech.org> Message-ID: <49D8DDEB.5010908@bbs.darktech.org> Trent Jarvi wrote: > You are responsible for cleaning up the serial ports when using threads. > That said, if the thread did shut down, finalize should have been called > if you are not passing the object around. See RXTXPort.java. > > protected void finalize() > { > if (debug) > z.reportln( "RXTXPort:finalize()"); > if( fd > 0 ) > { > if (debug) > z.reportln( "RXTXPort:calling close()"); > close(); > } > z.finalize(); > } Two points: 1) One should never rely on finalizers because they may never run. 2) RXTX shouldn't cause the entire JVM to crash if I misuse the API. The native code should recover more gracefully. > The exception is interesting. This is on Vista? Usually it just gives > an open error when another process has the port. Yes, this is on Vista 64-bit. I'd really like to see this bug fixed. Is this code compilable under Visual Studio? If so, I can debug the problem on my end and send you a patch. Thanks, Gili From cowwoc at bbs.darktech.org Sun Apr 5 10:36:20 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 12:36:20 -0400 Subject: [Rxtx] SerialPort.getName() is wrong In-Reply-To: References: <49D84E93.7050606@bbs.darktech.org> Message-ID: <49D8DE04.6030306@bbs.darktech.org> Trent Jarvi wrote: >> I am expecting the name to remain consistent. "//./COM5" looks like >> an implementation detail and (as far as I can tell) it can't be used as >> an argument for any API method so it is somewhat useless. If getName() >> were to return "COM5" I could at least use it to get back the original >> CommPortIdentifier or compare against "known names" such as "COMx" or >> "LPTx". What do you think? >> > > Sure. > > If it itches enough you should be able to fix this in RXTXCommDriver.java. I'm not sure I understand. Are you saying that if I submit a patch you will commit it? Gili From tjarvi at qbang.org Sun Apr 5 10:46:23 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Apr 2009 10:46:23 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D8DDEB.5010908@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> Message-ID: On Sun, 5 Apr 2009, cowwoc wrote: > Trent Jarvi wrote: >> You are responsible for cleaning up the serial ports when using threads. >> That said, if the thread did shut down, finalize should have been called if >> you are not passing the object around. See RXTXPort.java. >> >> protected void finalize() >> { >> if (debug) >> z.reportln( "RXTXPort:finalize()"); >> if( fd > 0 ) >> { >> if (debug) >> z.reportln( "RXTXPort:calling close()"); >> close(); >> } >> z.finalize(); >> } > > Two points: > > 1) One should never rely on finalizers because they may never run. > 2) RXTX shouldn't cause the entire JVM to crash if I misuse the API. The > native code should recover more gracefully. > >> The exception is interesting. This is on Vista? Usually it just gives an >> open error when another process has the port. > > Yes, this is on Vista 64-bit. I'd really like to see this bug fixed. > Is this code compilable under Visual Studio? If so, I can debug the problem > on my end and send you a patch. > It will compile with the msvc cl.exe and nmake. See Makefile.msvc in the top level directory. You will need to adjust the JAVA_HOME variable. Also use the MSVC command prompt for x86_64 so cl and nmake are on your path. All the best, -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Apr 5 10:49:10 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Apr 2009 10:49:10 -0600 (MDT) Subject: [Rxtx] SerialPort.getName() is wrong In-Reply-To: <49D8DE04.6030306@bbs.darktech.org> References: <49D84E93.7050606@bbs.darktech.org> <49D8DE04.6030306@bbs.darktech.org> Message-ID: On Sun, 5 Apr 2009, cowwoc wrote: > Trent Jarvi wrote: >>> I am expecting the name to remain consistent. "//./COM5" looks like >>> an implementation detail and (as far as I can tell) it can't be used as >>> an argument for any API method so it is somewhat useless. If getName() >>> were to return "COM5" I could at least use it to get back the original >>> CommPortIdentifier or compare against "known names" such as "COMx" or >>> "LPTx". What do you think? >>> >> >> Sure. >> >> If it itches enough you should be able to fix this in RXTXCommDriver.java. > > I'm not sure I understand. Are you saying that if I submit a patch > you will commit it? > Hi Gili, Post a patch here and if nobody complains, we will commit it and give you credit. Yep. Other issues like changing the API to use java5 that may break existing apps are likely to run into objections but bug fixes usually get fixed just as you mention. -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Sun Apr 5 10:55:07 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 12:55:07 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> Message-ID: <49D8E26B.2040705@bbs.darktech.org> Trent Jarvi wrote: > It will compile with the msvc cl.exe and nmake. See Makefile.msvc in > the top level directory. You will need to adjust the JAVA_HOME > variable. Also use the MSVC command prompt for x86_64 so cl and nmake > are on your path. This is very odd. The CVS version of the code does not contain this file. Do you keep the latest code somewhere else? Gili From cowwoc at bbs.darktech.org Sun Apr 5 11:01:58 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 13:01:58 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D8E26B.2040705@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> Message-ID: <49D8E406.10708@bbs.darktech.org> cowwoc wrote: > Trent Jarvi wrote: >> It will compile with the msvc cl.exe and nmake. See Makefile.msvc in >> the top level directory. You will need to adjust the JAVA_HOME >> variable. Also use the MSVC command prompt for x86_64 so cl and nmake >> are on your path. > > This is very odd. The CVS version of the code does not contain this > file. Do you keep the latest code somewhere else? Okay I figured it out. CVS head is out of date, the "commapi-0-0-1" revision contains the correct files. Gili From tjarvi at qbang.org Sun Apr 5 11:05:43 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Apr 2009 11:05:43 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D8E26B.2040705@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> Message-ID: CVS HEAD is currently the rxtx 2.0 code. A branch was created long ago for 'experimental' gnu.io work. It just happens that the branch is what everyone uses now. checkout -r commapi-0-0-1 rxtx-devel will get the branch On Sun, 5 Apr 2009, cowwoc wrote: > Trent Jarvi wrote: >> It will compile with the msvc cl.exe and nmake. See Makefile.msvc in the >> top level directory. You will need to adjust the JAVA_HOME variable. Also >> use the MSVC command prompt for x86_64 so cl and nmake are on your path. > > This is very odd. The CVS version of the code does not contain this > file. Do you keep the latest code somewhere else? > > Gili > From cowwoc at bbs.darktech.org Sun Apr 5 14:50:47 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 16:50:47 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> Message-ID: <49D919A7.1070806@bbs.darktech.org> Okay, I tracked down the crash. It's being caused by YACK() using a 80-character buffer. The error message is longer than 80 characters, so _snprintf_s() crashes to avoid a buffer overflow. Please apply the attached patch and add the zipped up Visual Studio project directory. It's not perfect yet but it's a good start. Gili Trent Jarvi wrote: > > CVS HEAD is currently the rxtx 2.0 code. A branch was created long > ago for 'experimental' gnu.io work. It just happens that the branch > is what everyone uses now. > > checkout -r commapi-0-0-1 rxtx-devel > > will get the branch > > On Sun, 5 Apr 2009, cowwoc wrote: > >> Trent Jarvi wrote: >>> It will compile with the msvc cl.exe and nmake. See Makefile.msvc >>> in the top level directory. You will need to adjust the JAVA_HOME >>> variable. Also use the MSVC command prompt for x86_64 so cl and >>> nmake are on your path. >> >> This is very odd. The CVS version of the code does not contain >> this file. Do you keep the latest code somewhere else? >> >> Gili >> -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx-devel.patch Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20090405/d9b82962/attachment-0007.pl -------------- next part -------------- A non-text attachment was scrubbed... Name: Win32.zip Type: application/octet-stream Size: 17764 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20090405/d9b82962/attachment-0009.obj From cowwoc at bbs.darktech.org Sun Apr 5 15:22:01 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 17:22:01 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D919A7.1070806@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> <49D919A7.1070806@bbs.darktech.org> Message-ID: <49D920F9.6080702@bbs.darktech.org> My mistake. The problem in YACK is real, but it isn't the real cause of the crash. The crash is caused by termios.c line 1099: index->prev->next = port; because in my case "index->prev==0". I think the bug is that the code assumes that index will contain a minimum of two entries if we're inserting a previously closed fd. In my case, it only contains one. I'm not sure why you have this code branch (as opposed to appending to the end of index). Please take a look. Thanks, Gili cowwoc wrote: > > Okay, I tracked down the crash. It's being caused by YACK() using a > 80-character buffer. The error message is longer than 80 characters, so > _snprintf_s() crashes to avoid a buffer overflow. > > Please apply the attached patch and add the zipped up Visual Studio > project directory. It's not perfect yet but it's a good start. > > Gili > > Trent Jarvi wrote: >> >> CVS HEAD is currently the rxtx 2.0 code. A branch was created long >> ago for 'experimental' gnu.io work. It just happens that the branch >> is what everyone uses now. >> >> checkout -r commapi-0-0-1 rxtx-devel >> >> will get the branch >> >> On Sun, 5 Apr 2009, cowwoc wrote: >> >>> Trent Jarvi wrote: >>>> It will compile with the msvc cl.exe and nmake. See Makefile.msvc >>>> in the top level directory. You will need to adjust the JAVA_HOME >>>> variable. Also use the MSVC command prompt for x86_64 so cl and >>>> nmake are on your path. >>> >>> This is very odd. The CVS version of the code does not contain >>> this file. Do you keep the latest code somewhere else? >>> >>> Gili >>> From tjarvi at qbang.org Sun Apr 5 16:13:27 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Apr 2009 16:13:27 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D920F9.6080702@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> <49D919A7.1070806@bbs.darktech.org> <49D920F9.6080702@bbs.darktech.org> Message-ID: Hi Gili, Are you using the cvs version? I thought we fixed the linked list issues. A solution was posted to the list. Let me look at work tomorrow to see what I have. On Sun, 5 Apr 2009, cowwoc wrote: > > My mistake. The problem in YACK is real, but it isn't the real cause > of the crash. The crash is caused by termios.c line 1099: > > index->prev->next = port; > > because in my case "index->prev==0". I think the bug is that the code > assumes that index will contain a minimum of two entries if we're inserting a > previously closed fd. In my case, it only contains one. > > I'm not sure why you have this code branch (as opposed to appending > to the end of index). Please take a look. > > Thanks, > Gili > > cowwoc wrote: >> >> Okay, I tracked down the crash. It's being caused by YACK() using a >> 80-character buffer. The error message is longer than 80 characters, so >> _snprintf_s() crashes to avoid a buffer overflow. >> >> Please apply the attached patch and add the zipped up Visual Studio >> project directory. It's not perfect yet but it's a good start. >> >> Gili >> >> Trent Jarvi wrote: >>> >>> CVS HEAD is currently the rxtx 2.0 code. A branch was created long ago >>> for 'experimental' gnu.io work. It just happens that the branch is what >>> everyone uses now. >>> >>> checkout -r commapi-0-0-1 rxtx-devel >>> >>> will get the branch >>> >>> On Sun, 5 Apr 2009, cowwoc wrote: >>> >>>> Trent Jarvi wrote: >>>>> It will compile with the msvc cl.exe and nmake. See Makefile.msvc in >>>>> the top level directory. You will need to adjust the JAVA_HOME >>>>> variable. Also use the MSVC command prompt for x86_64 so cl and nmake >>>>> are on your path. >>>> >>>> This is very odd. The CVS version of the code does not contain this >>>> file. Do you keep the latest code somewhere else? >>>> >>>> Gili >>>> > From ilkka at myller.com Sun Apr 5 23:58:08 2009 From: ilkka at myller.com (Ilkka Myller) Date: Mon, 6 Apr 2009 08:58:08 +0300 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> <49D919A7.1070806@bbs.darktech.org> <49D920F9.6080702@bbs.darktech.org> Message-ID: <19779C97-E0C7-4E3D-B715-F84F50F00CE6@myller.com> Hi all, I've already submitted the patch to fix this issue in february: http://mailman.qbang.org/pipermail/rxtx/2009-February/3989441.html The patch fixes the mentioned doubly linked list handling in termios.c -- I Trent Jarvi kirjoitti 6.4.2009 kello 1.13: > > Hi Gili, > > Are you using the cvs version? I thought we fixed the linked list > issues. > A solution was posted to the list. Let me look at work tomorrow to > see > what I have. > > > > On Sun, 5 Apr 2009, cowwoc wrote: > >> >> My mistake. The problem in YACK is real, but it isn't the real cause >> of the crash. The crash is caused by termios.c line 1099: >> >> index->prev->next = port; >> >> because in my case "index->prev==0". I think the bug is that the >> code >> assumes that index will contain a minimum of two entries if we're >> inserting a >> previously closed fd. In my case, it only contains one. >> >> I'm not sure why you have this code branch (as opposed to appending >> to the end of index). Please take a look. >> >> Thanks, >> Gili >> >> cowwoc wrote: >>> >>> Okay, I tracked down the crash. It's being caused by YACK() >>> using a >>> 80-character buffer. The error message is longer than 80 >>> characters, so >>> _snprintf_s() crashes to avoid a buffer overflow. >>> >>> Please apply the attached patch and add the zipped up Visual >>> Studio >>> project directory. It's not perfect yet but it's a good start. >>> >>> Gili >>> >>> Trent Jarvi wrote: >>>> >>>> CVS HEAD is currently the rxtx 2.0 code. A branch was created >>>> long ago >>>> for 'experimental' gnu.io work. It just happens that the branch >>>> is what >>>> everyone uses now. >>>> >>>> checkout -r commapi-0-0-1 rxtx-devel >>>> >>>> will get the branch >>>> >>>> On Sun, 5 Apr 2009, cowwoc wrote: >>>> >>>>> Trent Jarvi wrote: >>>>>> It will compile with the msvc cl.exe and nmake. See >>>>>> Makefile.msvc in >>>>>> the top level directory. You will need to adjust the JAVA_HOME >>>>>> variable. Also use the MSVC command prompt for x86_64 so cl and >>>>>> nmake >>>>>> are on your path. >>>>> >>>>> This is very odd. The CVS version of the code does not >>>>> contain this >>>>> file. Do you keep the latest code somewhere else? >>>>> >>>>> Gili >>>>> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Steffen.DETTMER at ingenico.com Mon Apr 6 02:53:47 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 6 Apr 2009 10:53:47 +0200 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D919A7.1070806@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> <49D919A7.1070806@bbs.darktech.org> Message-ID: <20090406085347.GM8289@elberon.bln.de.ingenico.com> Hi, just two minor details, first about the errno change, I though #include extern int errno; is correct (POSIX.1) - why this change? second about the log message, I think the maximum length could be limited and the return value of malloc must be checked for != NULL before using. Should it be _snprintf_s( message, 80, _TRUNCATE, "Error 0x%x at %s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); (I know that MS-CRT _snprintf does not guarantee to have a final EOS, but I think _snprintf_s with _TRUNCATE does so?). If it is known that truncation may happen maybe sizeof[message] could be increased; maybe using some %.20s could be used avoiding __FILE__ including big pathes to a message where all the message had been cut-off. To have it portable I think it could be: /* generally: */ #if defined(_MSC_VER) # define snprintf _snprintf #endif snprintf(message, sizeof(message), "Error 0x%x at %.20s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); message[sizeof(message)-1] = '\0'; /* needed for MS CRT snprintf */ (for length and size parameter I think size_t could be an option, but on several platforms, including MS-CRT and older glibc, there is no %z, unfortunately) oki, Steffen * cowwoc wrote on Sun, Apr 05, 2009 at 16:50 -0400: > > Okay, I tracked down the crash. It's being caused by YACK() using a > 80-character buffer. The error message is longer than 80 characters, so > _snprintf_s() crashes to avoid a buffer overflow. > > Please apply the attached patch and add the zipped up Visual Studio > project directory. It's not perfect yet but it's a good start. > > Gili > > Trent Jarvi wrote: > > > >CVS HEAD is currently the rxtx 2.0 code. A branch was created long > >ago for 'experimental' gnu.io work. It just happens that the branch > >is what everyone uses now. > > > >checkout -r commapi-0-0-1 rxtx-devel > > > >will get the branch > > > >On Sun, 5 Apr 2009, cowwoc wrote: > > > >>Trent Jarvi wrote: > >>>It will compile with the msvc cl.exe and nmake. See Makefile.msvc > >>>in the top level directory. You will need to adjust the JAVA_HOME > >>>variable. Also use the MSVC command prompt for x86_64 so cl and > >>>nmake are on your path. > >> > >> This is very odd. The CVS version of the code does not contain > >>this file. Do you keep the latest code somewhere else? > >> > >>Gili > >> > Index: ParallelImp.c > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/ParallelImp.c,v > retrieving revision 1.15.2.36 > diff -u -r1.15.2.36 ParallelImp.c > --- ParallelImp.c 11 Feb 2009 01:04:19 -0000 1.15.2.36 > +++ ParallelImp.c 5 Apr 2009 17:55:23 -0000 > @@ -119,7 +119,7 @@ > # include > #endif > > -extern int errno; > +_CRTIMP extern int * __cdecl _errno(void); > > #include "ParallelImp.h" > > @@ -181,8 +181,6 @@ > > #if defined (WIN32) > > -#define CTL_CODE( DeviceType, Function, Method, Access ) (((DeviceType) << 16) | ((Access) << 14) | ((Function) << 2) | (Method)) > - > #define FILE_DEVICE_PARALLEL_PORT 0x00000016 > #define METHOD_BUFFERED 0 > #define FILE_ANY_ACCESS 0 > @@ -253,7 +251,6 @@ > jobject jobj) > { > int fd = get_java_var( env, jobj,"fd","I" ); > - int status; > #if defined (__linux__) > ioctl(fd, LPGETSTATUS, &status); > #elif defined (WIN32) > Index: SerialImp.c > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v > retrieving revision 1.46.2.203 > diff -u -r1.46.2.203 SerialImp.c > --- SerialImp.c 19 Mar 2009 03:27:48 -0000 1.46.2.203 > +++ SerialImp.c 5 Apr 2009 17:49:48 -0000 > @@ -147,7 +147,7 @@ > #include > #endif /* LIBLOCKDEV */ > > -extern int errno; > +_CRTIMP extern int * __cdecl _errno(void); > > #include "SerialImp.h" > > Index: termios.c > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/termios.c,v > retrieving revision 1.9.2.62 > diff -u -r1.9.2.62 termios.c > --- termios.c 13 Jan 2009 03:08:55 -0000 1.9.2.62 > +++ termios.c 5 Apr 2009 17:54:09 -0000 > @@ -88,7 +88,7 @@ > #define SIGIO 0 > > int my_errno; > -extern int errno; > +_CRTIMP extern int * __cdecl _errno(void); > struct termios_list > { > char filename[80]; > @@ -1350,7 +1350,7 @@ > In that case use EAGAIN. See SerialImp.c:testRead() > ----------------------------------------------------------*/ > > -int serial_read( int fd, void *vb, int size ) > +int serial_read( int fd, void *vb, unsigned int size ) > { > long start, now; > unsigned long nBytes = 0, total = 0, error; > Index: win32termios.h > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/win32termios.h,v > retrieving revision 1.5.2.34 > diff -u -r1.5.2.34 win32termios.h > --- win32termios.h 5 Feb 2009 01:25:05 -0000 1.5.2.34 > +++ win32termios.h 5 Apr 2009 20:29:30 -0000 > @@ -60,6 +60,7 @@ > #include > #include > #include > +#include > #ifdef TRACE > #define ENTER(x) report("entering "x" \n"); > #define LEAVE(x) report("leaving "x" \n"); > @@ -70,8 +71,9 @@ > #if defined(_MSC_VER) > #define YACK() \ > { \ > - char *allocTextBuf, message[80]; \ > - unsigned long nChars; \ > + char *allocTextBuf, *message; \ > + const unsigned short longestNumber = 20; \ > + unsigned long nChars, len; \ > unsigned int errorCode = GetLastError(); \ > nChars = FormatMessage ( \ > FORMAT_MESSAGE_ALLOCATE_BUFFER | \ > @@ -82,8 +84,12 @@ > (LPSTR)&allocTextBuf, \ > 16, \ > NULL ); \ > - _snprintf_s( message, 80, 80, "Error 0x%x at %s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); \ > + len = strlen("Error 0x") + longestNumber + strlen(" at ") + strlen(__FILE__) + longestNumber + \ > + strlen(": ") + ((nChars+1) * sizeof(TCHAR)) + 1; \ > + message = malloc(len); \ > + _snprintf_s( message, len, len - 1, "Error 0x%x at %s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); \ > report_error( message ); \ > + free(message); \ > LocalFree(allocTextBuf); \ > Sleep(1); \ > } > @@ -173,7 +179,7 @@ > int serial_test( char * ); > int serial_open(const char *File, int flags, ... ); > int serial_close(int fd); > -int serial_read(int fd, void *b, int size); > +int serial_read(int fd, void *b, unsigned int size); > int serial_write(int fd, char *Str, int length); > /* > * lcc winsock.h conflicts > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx End of message. ------------------------------------------------------------------->8======= About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From bill7007 at gmail.com Mon Apr 6 16:34:50 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Mon, 6 Apr 2009 18:34:50 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: <49D693BA.8060909@gatworks.com> References: <49D546F8.20807@gatworks.com> <49D693BA.8060909@gatworks.com> Message-ID: Once it hung, three stack dumps minutes apart were exactly the same. I have a noticed that when it hangs, the read appears after flush() enter and before flush leave() that doesn't happen like: RXTXPort:SerialOutputStream:flush() enter RXTXPort:SerialInputStream:read(8192 0 8192) called When it works, flush() enter and leave happen together. It may just be because flush() hangs and read is the only other thread waiting to run at that point. I don't know much about the RXTX design and kernel interaction, just digging through the code some. Is there a design description somewhere? Am hung up on target system compile since UTS_RELEASE seems no longer defined for 2.6.18 up kernels and have not figured a good patch yet. But, that is another issue. Thanks for the good help. On Fri, Apr 3, 2009 at 6:54 PM, U. George wrote: > I would have tried 2 or 3 "^\" . If things are stuck, then all will be at > same 'java' instruction. If thread is moving, then one of the snapshots > would be different. > > I *think* flushing/draining wont return until the kernel buffers to device > have been accepted by device. Stuck/paused device? > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090406/c4b509d8/attachment-0008.html From tjarvi at qbang.org Mon Apr 6 17:45:38 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 6 Apr 2009 17:45:38 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <20090406085347.GM8289@elberon.bln.de.ingenico.com> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> <49D919A7.1070806@bbs.darktech.org> <20090406085347.GM8289@elberon.bln.de.ingenico.com> Message-ID: The error bits in the patch can probably just be dropped out. I don't see what they solve. Your snprintf define appears to work. The following is what I'd like to put in if noone objects. #if defined(_MSC_VER) # define snprintf _snprintf #endif #define YACK() \ { \ char *allocTextBuf, message[80]; \ unsigned long nChars; \ unsigned int errorCode = GetLastError(); \ nChars = FormatMessage ( \ FORMAT_MESSAGE_ALLOCATE_BUFFER | \ FORMAT_MESSAGE_FROM_SYSTEM, \ NULL, \ errorCode, \ MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT), \ (LPSTR)&allocTextBuf, \ 16, \ NULL ); \ snprintf( message, 80, "Error 0x%x at %s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); \ message[sizeof(message)-1] = '\0'; /* needed for MS CRT snprintf */ \ report_error( message ); \ LocalFree(allocTextBuf); \ Sleep(1); \ } On Mon, 6 Apr 2009, Steffen DETTMER wrote: > Hi, > > just two minor details, first about the errno change, I though > > #include > extern int errno; > > is correct (POSIX.1) - why this change? > > second about the log message, I think the maximum length could be > limited and the return value of malloc must be checked for != > NULL before using. > > Should it be > > _snprintf_s( message, 80, _TRUNCATE, "Error 0x%x at %s(%d): %s\n", > errorCode, __FILE__, __LINE__, allocTextBuf); > > (I know that MS-CRT _snprintf does not guarantee to have a final > EOS, but I think _snprintf_s with _TRUNCATE does so?). > > If it is known that truncation may happen maybe sizeof[message] > could be increased; maybe using some %.20s could be used avoiding > __FILE__ including big pathes to a message where all the message > had been cut-off. > > To have it portable I think it could be: > > /* generally: */ > #if defined(_MSC_VER) > # define snprintf _snprintf > #endif > > snprintf(message, sizeof(message), "Error 0x%x at %.20s(%d): %s\n", > errorCode, __FILE__, __LINE__, allocTextBuf); > message[sizeof(message)-1] = '\0'; /* needed for MS CRT snprintf */ > > (for length and size parameter I think size_t could be an option, > but on several platforms, including MS-CRT and older glibc, > there is no %z, unfortunately) > > oki, > > Steffen > > > * cowwoc wrote on Sun, Apr 05, 2009 at 16:50 -0400: >> >> Okay, I tracked down the crash. It's being caused by YACK() using a >> 80-character buffer. The error message is longer than 80 characters, so >> _snprintf_s() crashes to avoid a buffer overflow. >> >> Please apply the attached patch and add the zipped up Visual Studio >> project directory. It's not perfect yet but it's a good start. >> >> Gili >> >> Trent Jarvi wrote: >> > >> >CVS HEAD is currently the rxtx 2.0 code. A branch was created long >> >ago for 'experimental' gnu.io work. It just happens that the branch >> >is what everyone uses now. >> > >> >checkout -r commapi-0-0-1 rxtx-devel >> > >> >will get the branch >> > >> >On Sun, 5 Apr 2009, cowwoc wrote: >> > >> >>Trent Jarvi wrote: >> >>>It will compile with the msvc cl.exe and nmake. See Makefile.msvc >> >>>in the top level directory. You will need to adjust the JAVA_HOME >> >>>variable. Also use the MSVC command prompt for x86_64 so cl and >> >>>nmake are on your path. >> >> >> >> This is very odd. The CVS version of the code does not contain >> >>this file. Do you keep the latest code somewhere else? >> >> >> >>Gili >> >> > >> Index: ParallelImp.c >> =================================================================== >> RCS file: /usr/local/cvsroot/rxtx-devel/src/ParallelImp.c,v >> retrieving revision 1.15.2.36 >> diff -u -r1.15.2.36 ParallelImp.c >> --- ParallelImp.c 11 Feb 2009 01:04:19 -0000 1.15.2.36 >> +++ ParallelImp.c 5 Apr 2009 17:55:23 -0000 >> @@ -119,7 +119,7 @@ >> # include >> #endif >> >> -extern int errno; >> +_CRTIMP extern int * __cdecl _errno(void); >> >> #include "ParallelImp.h" >> >> @@ -181,8 +181,6 @@ >> >> #if defined (WIN32) >> >> -#define CTL_CODE( DeviceType, Function, Method, Access ) (((DeviceType) << 16) | ((Access) << 14) | ((Function) << 2) | (Method)) >> - >> #define FILE_DEVICE_PARALLEL_PORT 0x00000016 >> #define METHOD_BUFFERED 0 >> #define FILE_ANY_ACCESS 0 >> @@ -253,7 +251,6 @@ >> jobject jobj) >> { >> int fd = get_java_var( env, jobj,"fd","I" ); >> - int status; >> #if defined (__linux__) >> ioctl(fd, LPGETSTATUS, &status); >> #elif defined (WIN32) >> Index: SerialImp.c >> =================================================================== >> RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v >> retrieving revision 1.46.2.203 >> diff -u -r1.46.2.203 SerialImp.c >> --- SerialImp.c 19 Mar 2009 03:27:48 -0000 1.46.2.203 >> +++ SerialImp.c 5 Apr 2009 17:49:48 -0000 >> @@ -147,7 +147,7 @@ >> #include >> #endif /* LIBLOCKDEV */ >> >> -extern int errno; >> +_CRTIMP extern int * __cdecl _errno(void); >> >> #include "SerialImp.h" >> >> Index: termios.c >> =================================================================== >> RCS file: /usr/local/cvsroot/rxtx-devel/src/termios.c,v >> retrieving revision 1.9.2.62 >> diff -u -r1.9.2.62 termios.c >> --- termios.c 13 Jan 2009 03:08:55 -0000 1.9.2.62 >> +++ termios.c 5 Apr 2009 17:54:09 -0000 >> @@ -88,7 +88,7 @@ >> #define SIGIO 0 >> >> int my_errno; >> -extern int errno; >> +_CRTIMP extern int * __cdecl _errno(void); >> struct termios_list >> { >> char filename[80]; >> @@ -1350,7 +1350,7 @@ >> In that case use EAGAIN. See SerialImp.c:testRead() >> ----------------------------------------------------------*/ >> >> -int serial_read( int fd, void *vb, int size ) >> +int serial_read( int fd, void *vb, unsigned int size ) >> { >> long start, now; >> unsigned long nBytes = 0, total = 0, error; >> Index: win32termios.h >> =================================================================== >> RCS file: /usr/local/cvsroot/rxtx-devel/src/win32termios.h,v >> retrieving revision 1.5.2.34 >> diff -u -r1.5.2.34 win32termios.h >> --- win32termios.h 5 Feb 2009 01:25:05 -0000 1.5.2.34 >> +++ win32termios.h 5 Apr 2009 20:29:30 -0000 >> @@ -60,6 +60,7 @@ >> #include >> #include >> #include >> +#include >> #ifdef TRACE >> #define ENTER(x) report("entering "x" \n"); >> #define LEAVE(x) report("leaving "x" \n"); >> @@ -70,8 +71,9 @@ >> #if defined(_MSC_VER) >> #define YACK() \ >> { \ >> - char *allocTextBuf, message[80]; \ >> - unsigned long nChars; \ >> + char *allocTextBuf, *message; \ >> + const unsigned short longestNumber = 20; \ >> + unsigned long nChars, len; \ >> unsigned int errorCode = GetLastError(); \ >> nChars = FormatMessage ( \ >> FORMAT_MESSAGE_ALLOCATE_BUFFER | \ >> @@ -82,8 +84,12 @@ >> (LPSTR)&allocTextBuf, \ >> 16, \ >> NULL ); \ >> - _snprintf_s( message, 80, 80, "Error 0x%x at %s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); \ >> + len = strlen("Error 0x") + longestNumber + strlen(" at ") + strlen(__FILE__) + longestNumber + \ >> + strlen(": ") + ((nChars+1) * sizeof(TCHAR)) + 1; \ >> + message = malloc(len); \ >> + _snprintf_s( message, len, len - 1, "Error 0x%x at %s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); \ >> report_error( message ); \ >> + free(message); \ >> LocalFree(allocTextBuf); \ >> Sleep(1); \ >> } >> @@ -173,7 +179,7 @@ >> int serial_test( char * ); >> int serial_open(const char *File, int flags, ... ); >> int serial_close(int fd); >> -int serial_read(int fd, void *b, int size); >> +int serial_read(int fd, void *b, unsigned int size); >> int serial_write(int fd, char *Str, int length); >> /* >> * lcc winsock.h conflicts >> > > >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > > > > > > > > > > > > End of message. > ------------------------------------------------------------------->8======= > > > About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. > This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > P Please consider the environment before printing this e-mail > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Apr 6 18:11:28 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 6 Apr 2009 18:11:28 -0600 (MDT) Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: <49D546F8.20807@gatworks.com> <49D693BA.8060909@gatworks.com> Message-ID: UTS_RELEASE is defined in now. The check really should be removed from RXTX. It was a defensive check for wilder times when GNU glibc did not have defines the kernel headers had so rxtx would include the kernel headers instead. :/ If you don't have linux/version.h, it is generated when you configure the kernel. make oldconfig used to do the trick. It may make sense to work with the prerelease or CVS code. RXTX just assumes that flush, read and anything else the kernel exposes may be called at anytime from any thread. There isn't a design for the kernel interaction. There are higher level constraints put in Java to prevent some things happening at the same time with 'synchronized.' RXTXPort.java has all of those. When the port is opened, a native event thread is started which uses select to know if an event has happened. BSD like systems have a native thread that fires off on write which tries to flush() to determine when the output buffer is empty asynchronously. The rest is not marshaled in any fashion at the native level. T I think there is a lower level deadlock being triggered in flush as well. I don't think it should be possible if everything was right underneath us. You may want to examine the java code closer to make sure it isnt possible the lock is there. On Mon, 6 Apr 2009, Bill Johnson wrote: > Once it hung, three stack dumps minutes apart were exactly the same. > I have a noticed that when it hangs, the read appears after flush() enter and > before flush leave() that doesn't happen like: > RXTXPort:SerialOutputStream:flush() enter > RXTXPort:SerialInputStream:read(8192 0 8192) called > > When it works, flush() enter and leave happen together. It may just be because > flush() hangs and read is the only other thread waiting to run at that point. > I don't know much about the RXTX design and kernel interaction, just digging > through the code some. Is there a design description somewhere? > > Am hung up on target system compile since UTS_RELEASE seems no longer defined for > 2.6.18 up kernels and have not figured a good patch yet. But, that is another > issue. > > Thanks for the good help. > > > On Fri, Apr 3, 2009 at 6:54 PM, U. George wrote: > I would have tried 2 or 3 "^\" . If things are stuck, then all will be > at same 'java' instruction. If thread is moving, then one of the > snapshots would be different. > > I *think* flushing/draining wont return until the kernel buffers to > device have been accepted by device. Stuck/paused device? > > > > > From tjarvi at qbang.org Mon Apr 6 18:28:50 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 6 Apr 2009 18:28:50 -0600 (MDT) Subject: [Rxtx] CVS updates. Pre3 is comming. Message-ID: I need to go through the bugzilla reports prior to the pre3 release. I think this should be close if you want to check it out from CVS. added: YACK() debug overflow fix for windows Steffen DETTMER (and many others) multiport fix for windows. Ilkka Myller http://mailman.qbang.org/pipermail/rxtx/2009-February/3989441.html I think this code is current. If I missed something, yell. CVS Info: export/setenv CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login # passwd mousy cvs checkout -r commapi-0-0-1 rxtx-devel -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Apr 6 22:32:07 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 6 Apr 2009 22:32:07 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D919A7.1070806@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> <49D919A7.1070806@bbs.darktech.org> Message-ID: Ah. I'll put this in CVS tomorrow. I did sync up the code with my work sandbox today. I just forgot to pull and add this. On Sun, 5 Apr 2009, cowwoc wrote: > > Okay, I tracked down the crash. It's being caused by YACK() using a > 80-character buffer. The error message is longer than 80 characters, so > _snprintf_s() crashes to avoid a buffer overflow. > > Please apply the attached patch and add the zipped up Visual Studio > project directory. It's not perfect yet but it's a good start. > > Gili > > Trent Jarvi wrote: >> >> CVS HEAD is currently the rxtx 2.0 code. A branch was created long ago for >> 'experimental' gnu.io work. It just happens that the branch is what >> everyone uses now. >> >> checkout -r commapi-0-0-1 rxtx-devel >> >> will get the branch >> >> On Sun, 5 Apr 2009, cowwoc wrote: >> >>> Trent Jarvi wrote: >>>> It will compile with the msvc cl.exe and nmake. See Makefile.msvc in the >>>> top level directory. You will need to adjust the JAVA_HOME variable. >>>> Also use the MSVC command prompt for x86_64 so cl and nmake are on your >>>> path. >>> >>> This is very odd. The CVS version of the code does not contain this >>> file. Do you keep the latest code somewhere else? >>> >>> Gili >>> > From cowwoc at bbs.darktech.org Tue Apr 7 06:07:46 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Tue, 07 Apr 2009 08:07:46 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: References: Message-ID: <49DB4212.40807@bbs.darktech.org> > just two minor details, first about the errno change, I though > > #include > extern int errno; > > is correct (POSIX.1) - why this change? If you compile this under Visual Studio 2008 you will get warnings that the errno type being imported is different from the type being exported. The definition I pasted is the one being exported. Perhaps we should use #ifdef WIN32 for this? Gili From bill7007 at gmail.com Tue Apr 7 17:58:54 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Tue, 7 Apr 2009 19:58:54 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: <49D546F8.20807@gatworks.com> <49D693BA.8060909@gatworks.com> Message-ID: I have traced the hang down to a call to tcdrain(fd) in SerialImp.c:drain() running and rebuilt under Netbeans on the target machine with debug messages on. That puts it into the system code, so I'm not sure how to proceed. I guess I could debug into the kernel source but I've not done that. I saw some discussion about an IOCTL that sets/adjusts a timeout on tcdrain() but that may have been for BSD. Maybe there is some new setup requirement or bug introduced with this 2.6.18 kernel or a hardware difference. Below is a message listing with some of the repeated parts removed. Maybe you can see something noteworthy? JNI_OnLoad called. WARNING: RXTX Version mismatch Jar version = RXTX-2.2pre2 native lib Version = RXTX-2.2pre3 entering RXTXCommDriver:getDeviceDirectory entering RXTXPort:testRead fhs_lock: creating lockfile: 29704 fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXPort:testRead RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB2 fhs_lock: creating lockfile: 29704 fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXPort:testRead RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB1 fhs_lock: creating lockfile: 29704 fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXPort:testRead RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB0 fhs_lock: creating lockfile: 29704 fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXPort:testRead fhs_lock: creating lockfile: 29704 ... REPEATS fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXPort:testRead fhs_lock: creating lockfile: 29704 fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXCommDriver:getDeviceDirectory entering RXTXPort:testRead fhs_lock: creating lockfile: 29704 ...REPEATS fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXPort:testRead fhs_lock: creating lockfile: 29704 fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXPort:Initialize RXTX WARNING: This library was compiled to run with OS release 2.6.18 and you are currently running OS release 2.6.18-92.1.6.el5. In some cases this can be a problem. Try recompiling RXTX if you notice strange behavior. If you just compiled RXTX make sure /usr/include/linux is a symbolic link to the include files that came with the kernel source and not an older copy. press enter to continue leaving RXTXPort:Initialize entering RXTXPort:open fhs_lock: creating lockfile: 29704 open: locking worked for /dev/ttyUSB2 open: fd returned is 9 leaving RXTXPort:open entering eventLoop has_line_status_register_acess: Port does not support TIOCSERGETLSR driver_has_tiocgicount: Port does not support TIOCGICOUNT events init_threads: get eis init_threads: set eis init_threads: stop leaving RXTXPort:translate_speed entering RXTXPort:nativeSetSerialPortParams entering translate_date_bits entering translate_stop_bits leaving RXTXPort:translate_stop_bits entering translate_parity leaving translate_parity entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 ...REPEATS entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 leaving RXTXPort:nativeSetSerialPortParams entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 ...REPEATS entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 entering writeArray entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 writeArray() leaving RXTXPort:writeArray entering SerialImp.c:drain() nativeDrain: trying tcdrain RXTXPort:drain() returns: 0 leaving RXTXPort:drain() entering writeArray writeArray() leaving RXTXPort:writeArray entering SerialImp.c:drain() nativeDrain: trying tcdrain entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 Tue Apr 07 18:51:49 EDT 2009:TSerial[22]:Using Port:/dev/ttyUSB2 Tue Apr 07 18:51:49 EDT 2009:TSerial[22].Transmit:TN Tue Apr 07 18:51:49 EDT 2009:TSerial[22].Transmit:RV entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 ...REPEATS FOREVER? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090407/f26e5752/attachment-0007.html From tjarvi at qbang.org Tue Apr 7 18:31:23 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 7 Apr 2009 18:31:23 -0600 (MDT) Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: <49D546F8.20807@gatworks.com> <49D693BA.8060909@gatworks.com> Message-ID: On Tue, 7 Apr 2009, Bill Johnson wrote: > I have traced the hang down to a call to tcdrain(fd) in SerialImp.c:drain() > running and rebuilt under Netbeans on the target machine with debug messages > on. That puts it into the system code, so I'm not sure how to proceed. I > guess I could debug into the kernel source but I've not done that. I saw > some discussion about an IOCTL that sets/adjusts a timeout on tcdrain() but > that may have been for BSD. Maybe there is some new setup requirement or bug > introduced with this 2.6.18 kernel or a hardware difference. > Below is a message listing with some of the repeated parts removed. Maybe > you can see something noteworthy? > > JNI_OnLoad called. > WARNING:? RXTX Version mismatch > ??????? Jar version = RXTX-2.2pre2 > ??????? native lib Version = RXTX-2.2pre3 > entering RXTXCommDriver:getDeviceDirectory > entering RXTXPort:testRead > fhs_lock: creating lockfile:????? 29704 > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXPort:testRead > RXTX Warning:? Removing stale lock file. /var/lock/LCK..ttyUSB2 > fhs_lock: creating lockfile:????? 29704 > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXPort:testRead > RXTX Warning:? Removing stale lock file. /var/lock/LCK..ttyUSB1 > fhs_lock: creating lockfile:????? 29704 > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXPort:testRead > RXTX Warning:? Removing stale lock file. /var/lock/LCK..ttyUSB0 > fhs_lock: creating lockfile:????? 29704 > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXPort:testRead > fhs_lock: creating lockfile:????? 29704 > > ... REPEATS > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXPort:testRead > fhs_lock: creating lockfile:????? 29704 > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXCommDriver:getDeviceDirectory > entering RXTXPort:testRead > fhs_lock: creating lockfile:????? 29704 > > ...REPEATS > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXPort:testRead > fhs_lock: creating lockfile:????? 29704 > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXPort:Initialize > > > > RXTX WARNING:? This library was compiled to run with OS release 2.6.18 and > you are currently running OS release 2.6.18-92.1.6.el5.? In some cases this > can be a problem.? Try recompiling RXTX if you notice strange behavior.? If > you just compiled RXTX make sure /usr/include/linux is a symbolic link to > the include files that came with the kernel source and not an older copy. > > > press enter to continue > > leaving RXTXPort:Initialize > entering RXTXPort:open > fhs_lock: creating lockfile:????? 29704 > > open: locking worked for /dev/ttyUSB2 > open: fd returned is 9 > leaving RXTXPort:open > entering eventLoop > ? > has_line_status_register_acess: Port does not support TIOCSERGETLSR > ?driver_has_tiocgicount:? Port does not support TIOCGICOUNT events > init_threads: get eis > init_threads: set eis > init_threads:? stop > leaving RXTXPort:translate_speed > entering RXTXPort:nativeSetSerialPortParams > entering translate_date_bits > entering translate_stop_bits > leaving RXTXPort:translate_stop_bits > entering translate_parity > leaving translate_parity > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > ...REPEATS > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > leaving RXTXPort:nativeSetSerialPortParams > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > ...REPEATS > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > entering writeArray > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > writeArray() > leaving RXTXPort:writeArray > entering SerialImp.c:drain() > nativeDrain: trying tcdrain > RXTXPort:drain() returns: 0 > leaving RXTXPort:drain() > entering writeArray > writeArray() > leaving RXTXPort:writeArray > entering SerialImp.c:drain() > nativeDrain: trying tcdrain > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > Tue Apr 07 18:51:49 EDT 2009:TSerial[22]:Using Port:/dev/ttyUSB2 > Tue Apr 07 18:51:49 EDT 2009:TSerial[22].Transmit:TN > > Tue Apr 07 18:51:49 EDT 2009:TSerial[22].Transmit:RV > > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > ...REPEATS FOREVER? > > > Hi Bill ugh. The tiocmget... is the eventLoop checking for events. It sits with select() but has a timeout value to keep it spinning at a trivial rate. tcdrain() is the suspect. I don't see anything in the code that looks like a problem. If flow control is not enabled, I don't see a reason for it not to return. Given that this is USB, perhaps a message from the device got lost. Onboard UARTs would have a status register change when output buffer is empty. USB needs to communicate the event as an HID device which may be the source of the error. Dropping back to onboard UARTs eliminates that portion of the mix. What vendor/chipset is the USB dongle? I understand code has been pushed upon the linux serial devices for new for things like acpi. There very well could be a bug introduced. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Apr 7 18:38:22 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 7 Apr 2009 18:38:22 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49DB4212.40807@bbs.darktech.org> References: <49DB4212.40807@bbs.darktech.org> Message-ID: On Tue, 7 Apr 2009, cowwoc wrote: >> just two minor details, first about the errno change, I though >> >> #include >> extern int errno; >> >> is correct (POSIX.1) - why this change? > > If you compile this under Visual Studio 2008 you will get warnings that > the errno type being imported is different from the type being exported. > The definition I pasted is the one being exported. Perhaps we should use > #ifdef WIN32 for this? > Hi Gili, Perhaps a workaround for _MSVC is in order. GNU compilers for windows won't complain. If it's a question of MSVC or POSIX being right, the library favors the standard as a stated goal. I'm not sure what MSVC is using errno for but it should not be using it except with POSIX extensions. Perhaps #undef is enough to get rid of the warning and (maybe) has no ill consequences. Newer windows have POSIX extensions that may show how Microsoft solved the problem. It can probably fester. -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Tue Apr 7 19:54:06 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Tue, 07 Apr 2009 21:54:06 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: References: <49DB4212.40807@bbs.darktech.org> Message-ID: <49DC03BE.5010203@bbs.darktech.org> Trent Jarvi wrote: > I'm not sure what MSVC is using errno for but it should not be using it > except with POSIX extensions. Perhaps #undef is enough to get rid of > the warning and (maybe) has no ill consequences. Newer windows have > POSIX extensions that may show how Microsoft solved the problem. > > It can probably fester. What does "newer windows" refer to in this case? I was compiling using Visual Studio 2008 sp1 under Windows Vista. Both are cutting edge technologies as far as official releases go. I think you're best suited to judge whether this warning is a big deal or not so I think you should see it for yourself. Please try firing up Visual Studio 2008 (express?) against the project I sent you. Gili From Steffen.DETTMER at ingenico.com Wed Apr 8 05:50:42 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 8 Apr 2009 13:50:42 +0200 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49DC03BE.5010203@bbs.darktech.org> References: <49DB4212.40807@bbs.darktech.org> <49DC03BE.5010203@bbs.darktech.org> Message-ID: <20090408115042.GC5090@elberon.bln.de.ingenico.com> * cowwoc wrote on Tue, Apr 07, 2009 at 21:54 -0400: > Trent Jarvi wrote: > > I'm not sure what MSVC is using errno for but it should not be using it > > except with POSIX extensions. Perhaps #undef is enough to get rid of > > the warning and (maybe) has no ill consequences. Newer windows have > > POSIX extensions that may show how Microsoft solved the problem. I think here best is simply to omit this old^Wclassic `extern int errno;' line completely. I think standards just say something like `implementations may support the declaration extern int errno;'. About POSIX extensions I think in general it should be considered that althrough many things are available, even with MS Visual C++, the Microsoft tools lead developers to write non-portable code (and personally I think this is intentional). For example, they call the official ISO-C function `strerror' deprecated (!) and twaddle about some security enhancements (without even beeing specific). Someone could, because of this, lead to use the MS specific, unportable `strerror_s' instead. Even better, at _strerror_s they tell, for `ANSI compatiblity someone should use strerror_s'. Of course a program using [_]strerror_s won't be ANSI-C compliant. Do they mean strerror_r? _strerror_s has the same parameters - but of course in different order - to make porting a pain... SCNR. > What does "newer windows" refer to in this case? I was compiling using > Visual Studio 2008 sp1 under Windows Vista. Both are cutting edge > technologies as far as official releases go. `cutting edge technologies' yeah post-standard, portability-cutting technologies smoothing the way to MS world domination; own post-ANSI-C programming languages help (maybe to increase the share holder value)... SCNR. > I think you're best suited to judge whether this warning is a big deal > or not so I think you should see it for yourself. Please try firing up > Visual Studio 2008 (express?) against the project I sent you. yeah, getting the CL.EXE of 2008 running in a normal command line environment (without its special `C++ Shell') is a bit tricky - but possible. ;) oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From tjarvi at qbang.org Wed Apr 8 14:29:54 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 8 Apr 2009 14:29:54 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49DC03BE.5010203@bbs.darktech.org> References: <49DB4212.40807@bbs.darktech.org> <49DC03BE.5010203@bbs.darktech.org> Message-ID: The support has been around for a long time to. I don't know the details but the support appears to be tied to the OS. http://en.wikipedia.org/wiki/POSIX#POSIX_for_Windows On Tue, 7 Apr 2009, cowwoc wrote: > Trent Jarvi wrote: >> I'm not sure what MSVC is using errno for but it should not be using it >> except with POSIX extensions. Perhaps #undef is enough to get rid of the >> warning and (maybe) has no ill consequences. Newer windows have POSIX >> extensions that may show how Microsoft solved the problem. >> >> It can probably fester. > > What does "newer windows" refer to in this case? I was compiling > using Visual Studio 2008 sp1 under Windows Vista. Both are cutting edge > technologies as far as official releases go. > > I think you're best suited to judge whether this warning is a big > deal or not so I think you should see it for yourself. Please try firing up > Visual Studio 2008 (express?) against the project I sent you. > > Gili > From bill7007 at gmail.com Wed Apr 8 15:59:08 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Wed, 8 Apr 2009 17:59:08 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: <49D546F8.20807@gatworks.com> <49D693BA.8060909@gatworks.com> Message-ID: Hi Trent, I think I have hit on a work around but don't know why it works. The USB serial adapter is a "CableMAX" based on Prolific's PL2303. Backing out to the big picture, the application is old and has been very reliable until put on a new cpu and kernel. It only hangs sometimes say 25% and always at the same place, at tcdrain() on the flush() after the second write after startup. If it made it past this stage, all transmit and receive seemed reliable so it was like a startup timing issue. Since learning to debug kernel code is beyond my immediate priority, I took a shot at moving code around, adding delays, and such. I have found it good practice to do a flush after every write on streams like: outputStream.write(data.getBytes()); outputStream.flush(); If I remove the flush() after each write, the problem appears to go away! I don't think the flush is needed for a SerialOutputStream for this application anyway. Thanks for all the help, +BillJ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090408/35d96a9d/attachment-0005.html From bill7007 at gmail.com Thu Apr 9 09:20:11 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Thu, 9 Apr 2009 11:20:11 -0400 Subject: [Rxtx] Baud rate fixes in 2.2pre2 breaks 38400 on some Linux devices Message-ID: Hello, An application that worked at 38400 on a USB serial adapter (PL2303) using 2.1-7-r2 on Linux EL4 (and EL5) now fails using 2.2pre2. serialPort.setSerialPortParams(38400,SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); throws an unsupportedCommOperationException This problem matched a description of Bug 113and I posted a proposed patch there, but I don't understand the whole custom baud rate patch so it may need some thought. An older patch, [Rxtx] [Patch]: Baud Rate fixes try 1, testing encouraged., fixed some custom baud rates but apparently broke 38400 on some Linux device. Other baud rates seem to work OK. And, 38400 tested OK on local non-USB ports. My proposed patch probably breaks the custom baud rate patch since it was keyed on 38400 as a special case for Linux and my fix was to back out part of that patch, specifically: #if defined(TIOCGSERIAL) if ( cspeed == B38400 ) cspeed = 38400; #endif /* TIOCGSERIAL */ +BillJ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090409/5636af64/attachment-0004.html From cowwoc at bbs.darktech.org Fri Apr 10 08:38:49 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Fri, 10 Apr 2009 10:38:49 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: References: <49DB4212.40807@bbs.darktech.org> <49DC03BE.5010203@bbs.darktech.org> Message-ID: <49DF59F9.2050408@bbs.darktech.org> Doesn't Wikipedia list as an optional sub-system? Gili Trent Jarvi wrote: > > The support has been around for a long time to. I don't know the > details but the support appears to be tied to the OS. > > http://en.wikipedia.org/wiki/POSIX#POSIX_for_Windows > > On Tue, 7 Apr 2009, cowwoc wrote: > >> Trent Jarvi wrote: >>> I'm not sure what MSVC is using errno for but it should not be using >>> it except with POSIX extensions. Perhaps #undef is enough to get >>> rid of the warning and (maybe) has no ill consequences. Newer >>> windows have POSIX extensions that may show how Microsoft solved the >>> problem. >>> >>> It can probably fester. >> >> What does "newer windows" refer to in this case? I was compiling >> using Visual Studio 2008 sp1 under Windows Vista. Both are cutting >> edge technologies as far as official releases go. >> >> I think you're best suited to judge whether this warning is a big >> deal or not so I think you should see it for yourself. Please try >> firing up Visual Studio 2008 (express?) against the project I sent you. >> >> Gili >> From eranshuman at gmail.com Mon Apr 13 04:50:34 2009 From: eranshuman at gmail.com (Anshuman Srivastava) Date: Mon, 13 Apr 2009 16:20:34 +0530 Subject: [Rxtx] Send RTS /DTR signal Message-ID: <589913a50904130350n59cc51ffvbcd0a4eaefb4ce5f@mail.gmail.com> Hi, I want to send the RTS or DTR signal from the application Can anybody telll how to send the DTR /RTS signal using rxtxcomm libraries Thanks and regards -- Anshuman Srivastava "... in the end, it's not the years in your life that count. It's the life in your years." Buzz +91 9962515155 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090413/211b5ded/attachment-0001.html From ajmas at sympatico.ca Mon Apr 13 09:50:47 2009 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 13 Apr 2009 11:50:47 -0400 Subject: [Rxtx] Wiki Spam pages - need of captcha? Message-ID: Hi Trent, While checking for spam pages in the wiki I came across a page containing the following: "NOTICE: This page was created by a program as part of the Graffiti Network research project at Brown University. We have removed the data, but are unable to remove this page. We apologize for any inconveniences that our actions may have caused. For more information, please visit http://graffiti.cs.brown.edu/info/." Is there any chance we could add a captcha to account registration? Andr?-John From sguido at micromotive.net Mon Apr 13 09:46:15 2009 From: sguido at micromotive.net (Samuel Guido) Date: Mon, 13 Apr 2009 11:46:15 -0400 Subject: [Rxtx] Serial Output Stream Hangs on Windows Message-ID: <843C9F1C-72EE-4A40-B02A-3798EB0C57BF@micromotive.net> All, I am using RXTX in a small application to talk to a remote embedded device on a Windows host. All data is ASCII text. On physical comm ports, everything seems to be fine, messages are sent and received without much trouble. I am also trying to make the comm port selection automatic where I cycle through the available comm ports sending messages until I get the expected response. Unfortunately, when I query for the available comm ports, the bluetooth ports also show up. Whenever I try to send a string of characters to the bluetooth port, RXTX hangs way down in the call stack in the output stream, I believe in the DLL. I tried both the 2.1.7r2 and the 2.2pre2 releases and both have the same result. The send and receiving of messages from the comm port are in their own threads, but once the thread is blocked, I can't do anything with the comm ports since they are synchronized calls. The bluetooth ports are using a driver call "WIDCOMM" which I don't know who/what that is. This is on a IBM T42 laptop machine. Does anyone know what could be causing this? Is there a way to distinguish between bluetooth ports and physical comm ports? Please help, I am on a tight deadline and any help would greatly be appreciated. Thanks very much. Sam Guido From ajmas at sympatico.ca Mon Apr 13 11:04:24 2009 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 13 Apr 2009 13:04:24 -0400 Subject: [Rxtx] RxTX mentioned on Sun's Java Communications page Message-ID: Looks like RxTx gets some mention at Sun: Head over to the Java Communications page http://java.sun.com/products/javacomm/ and then click on Downloads and you get: " COMM API is a Java extension providing access to RS-232 serial ports and IEEE-1284 parallel ports (SPP mode). Sun Ray platform support is provided. Documentation and sample code are included, as well as interactive test utilities. API serial features provide access to: * Port settings (baud rate, parity, stop bits) * Port naming, mapping, enumeration (configurable) * Data transfer over TX, RX lines * DTR, CD, CTS, RTS and DSR signals * Hardware/Software flow-control * Receive-buffer threshold control * Asynchronous events indicating: * Data available on an RS-232 port * Port hardware line level changes * Port ownership changes within a JVM Update History: * javax.comm 3.0, Update 1 o Fixed problems locating and parsing portmap.conf * javax.comm 3.0, FCS o Redesigned portmapping and Sun Ray interoperability (see bundled documentation) * 2.0.3: o Added portmapping (comm.jar available 'as-is' for 3rd party native lib support)* Several Bugfixes to 2.0.3 (see bundled release notes) Note: Sun no longer offer's the Windows platform binaries of javax.comm, however javax.comm 2.0.3 can be used for the Windows platform, by using it in conjunction with the Win32 implementation layer provided by the RxTx project. To use that, download javax.comm for the 'generic' platform (which provides the front-end javax.comm API only, without platform specific back-end implementations bundled). Then acquire the Windows binary implementation rxtx-2.0.7pre1 from http://www.rxtx.org . " Looks like RxTx really is the closest thing we have to the 'official' implementation. From tjarvi at qbang.org Mon Apr 13 12:27:44 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 13 Apr 2009 12:27:44 -0600 (MDT) Subject: [Rxtx] RxTX mentioned on Sun's Java Communications page In-Reply-To: References: Message-ID: On Mon, 13 Apr 2009, Andre-John Mas wrote: > Looks like RxTx gets some mention at Sun: > > Head over to the Java Communications page http://java.sun.com/products/javacomm/ > and then click on Downloads and you get: > > " > COMM API is a Java extension providing access to RS-232 serial ports > and IEEE-1284 parallel ports (SPP mode). Sun Ray platform support is > provided. Documentation and sample code are included, as well as > interactive test utilities. API serial features provide access to: * > Port settings (baud rate, parity, stop bits) * Port naming, mapping, > enumeration (configurable) * Data transfer over TX, RX lines * DTR, > CD, CTS, RTS and DSR signals * Hardware/Software flow-control * > Receive-buffer threshold control * Asynchronous events indicating: * > Data available on an RS-232 port * Port hardware line level changes * > Port ownership changes within a JVM Update History: * javax.comm 3.0, > Update 1 o Fixed problems locating and parsing portmap.conf * > javax.comm 3.0, FCS o Redesigned portmapping and Sun Ray > interoperability (see bundled documentation) * 2.0.3: o Added > portmapping (comm.jar available 'as-is' for 3rd party native lib > support)* Several Bugfixes to 2.0.3 (see bundled release notes) Note: > Sun no longer offer's the Windows platform binaries of javax.comm, > however javax.comm 2.0.3 can be used for the Windows platform, by > using it in conjunction with the Win32 implementation layer provided > by the RxTx project. To use that, download javax.comm for the > 'generic' platform (which provides the front-end javax.comm API only, > without platform specific back-end implementations bundled). Then > acquire the Windows binary implementation rxtx-2.0.7pre1 from http://www.rxtx.org > .. > " > > Looks like RxTx really is the closest thing we have to the 'official' > implementation. Ugh. I don't know of any developer interest in maintaining rxtx 2.0. It would be cleaner for Sun to just openly take javax.comm for their Sun Ray project. If someone is interested in maintaining rxtx 2.0, don't be afraid to say so. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Mon Apr 13 16:04:19 2009 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 13 Apr 2009 17:04:19 -0500 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D8DDEB.5010908@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> Message-ID: <49E3B6E3.5050203@cox.net> cowwoc wrote: > Trent Jarvi wrote: >> You are responsible for cleaning up the serial ports when using threads. >> That said, if the thread did shut down, finalize should have been called >> if you are not passing the object around. See RXTXPort.java. >> >> protected void finalize() >> { >> if (debug) >> z.reportln( "RXTXPort:finalize()"); >> if( fd > 0 ) >> { >> if (debug) >> z.reportln( "RXTXPort:calling close()"); >> close(); >> } >> z.finalize(); >> } > > Two points: > > 1) One should never rely on finalizers because they may never run. A PhantomRef is the way to do this kind of cleanup in most cases. It will always fire. The real issue is that you have to understand that the on the Sun JVM, the GC can run finalization or advertise a dropped reference before an object is actually unreferenced in some cases. This happens, predominately in blocks of code where object references are short lived with no class member reference that the GC can find. When the JIT compiled code just references an object on the local stack and/or a register, the GC can prematurely attempt finalization/PhantomRef notification and result in bad things happening. The single solution to this problem is to use synchronize(obj){} at the end of the block of code that obj lives in, which keeps the object from getting reclaimed prematurely. For the sake of application sanity and recovery from erroneous code, it's almost always best to put resources like this into a map, accessed by name, and make an API method that lets you find the object by name, rather than by instance reference. Then, in your code, when you want to open a serial port, you'd do something like the following, which will close anything you already opened and then open it back up. Map ports = ...; public void closePort( String port ) { CommPort p = null; p = ports.remove(port); if( p != null ) p.close(); } public CommPort public CommPort openPort( String port, String user, int timeout ) throws IOException { closePort( port ); CommPort p = CommPortIdentifier.getPortIdentifier(port). open( user, timeout ); ports.put( port, p ); return p; } Appropriate use of synchronized(ports) may be necessary if ports is not referencing a concurrency safe Map implementation such as Hashtable or ConcurrentHashMap. Gregg Wonderly From gergg at cox.net Mon Apr 13 16:36:57 2009 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 13 Apr 2009 17:36:57 -0500 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: <49D546F8.20807@gatworks.com> <49D693BA.8060909@gatworks.com> Message-ID: <49E3BE89.4020402@cox.net> Check CTS/RTS and DTR/CD etc on the device to make sure you haven't hung the kernel trying to clean up something, but it's now waiting for CTS etc. In general, you should be careful about using HW flow control when cables can be trivially unplugged or broken. Use application layer checksums or similar things to make sure data that is flowing is sane and that buffers have not overrun, resulting in lost data. Gregg Wonderly Trent Jarvi wrote: > UTS_RELEASE is defined in now. The check really should > be removed from RXTX. It was a defensive check for wilder times when GNU > glibc did not have defines the kernel headers had so rxtx would include > the kernel headers instead. :/ > > If you don't have linux/version.h, it is generated when you configure the > kernel. make oldconfig used to do the trick. It may make sense to work > with the prerelease or CVS code. > > RXTX just assumes that flush, read and anything else the kernel exposes > may be called at anytime from any thread. There isn't a design for the > kernel interaction. There are higher level constraints put in Java to > prevent some things happening at the same time with 'synchronized.' > RXTXPort.java has all of those. > > When the port is opened, a native event thread is started which uses > select to know if an event has happened. > > BSD like systems have a native thread that fires off on write which tries > to flush() to determine when the output buffer is empty asynchronously. > > The rest is not marshaled in any fashion at the native level. T > > I think there is a lower level deadlock being triggered in flush as well. > I don't think it should be possible if everything was right underneath us. > You may want to examine the java code closer to make sure it isnt possible > the lock is there. > > > On Mon, 6 Apr 2009, Bill Johnson wrote: > >> Once it hung, three stack dumps minutes apart were exactly the same. >> I have a noticed that when it hangs, the read appears after flush() enter and >> before flush leave() that doesn't happen like: >> RXTXPort:SerialOutputStream:flush() enter >> RXTXPort:SerialInputStream:read(8192 0 8192) called >> >> When it works, flush() enter and leave happen together. It may just be because >> flush() hangs and read is the only other thread waiting to run at that point. >> I don't know much about the RXTX design and kernel interaction, just digging >> through the code some. Is there a design description somewhere? >> >> Am hung up on target system compile since UTS_RELEASE seems no longer defined for >> 2.6.18 up kernels and have not figured a good patch yet. But, that is another >> issue. >> >> Thanks for the good help. >> >> >> On Fri, Apr 3, 2009 at 6:54 PM, U. George wrote: >> I would have tried 2 or 3 "^\" . If things are stuck, then all will be >> at same 'java' instruction. If thread is moving, then one of the >> snapshots would be different. >> >> I *think* flushing/draining wont return until the kernel buffers to >> device have been accepted by device. Stuck/paused device? >> >> >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From cowwoc at bbs.darktech.org Mon Apr 13 20:41:20 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Mon, 13 Apr 2009 22:41:20 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49E3B6E3.5050203@cox.net> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49E3B6E3.5050203@cox.net> Message-ID: <49E3F7D0.5090207@bbs.darktech.org> Gregg Wonderly wrote: > A PhantomRef is the way to do this kind of cleanup in most cases. It > will always fire. The real issue is that you have to understand that > the on the Sun JVM, the GC can run finalization or advertise a dropped > reference before an object is actually unreferenced in some cases. This > happens, predominately in blocks of code where object references are > short lived with no class member reference that the GC can find. When > the JIT compiled code just references an object on the local stack > and/or a register, the GC can prematurely attempt > finalization/PhantomRef notification and result in bad things happening. I've never seen this myself. Can you reproduce it on the latest JRE? If so, this sounds like a bug to me and should be fixed. Please consider filing a bug report and telling me the bug number. I'll try running it by my Sun contacts. Gili From ferry_new2004 at yahoo.com Mon Apr 13 21:24:59 2009 From: ferry_new2004 at yahoo.com (Ferry Sumendap) Date: Mon, 13 Apr 2009 20:24:59 -0700 (PDT) Subject: [Rxtx] In Linux, RXTX serial port lib cannot send character which hex is more than 127. Message-ID: <30875.39589.qm@web33106.mail.mud.yahoo.com> Hello everybody, I have just tested the RXTXserial port library version RXTX2-1-7pre20 to send two characters which are character ascii 230 and 234. It seems that the driver somehow did not send the two characters into serial port if the Operating System is Linux Mandriva 2007 (kernel version 2.6.17-13mdv ) or Linux Mandriva 2009. I also tried the driver using same java code (java class file of the program I wrote), in Windows XP, it does work. Should I configure something (special configuration in Linux) or did I miss something ? I also have tested the latest RXTX 2.2pre2 driver, but it still have that problem. Regards, Ferry -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090413/94fdfbea/attachment.html From tjarvi at qbang.org Mon Apr 13 22:01:04 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 13 Apr 2009 22:01:04 -0600 (MDT) Subject: [Rxtx] In Linux, RXTX serial port lib cannot send character which hex is more than 127. In-Reply-To: <30875.39589.qm@web33106.mail.mud.yahoo.com> References: <30875.39589.qm@web33106.mail.mud.yahoo.com> Message-ID: On Mon, 13 Apr 2009, Ferry Sumendap wrote: > Hello everybody, > > I have just tested the RXTXserial port library version? RXTX2-1-7pre20 to > send two characters which are character ascii? 230 and 234. It seems that > the driver somehow did not send the two characters into serial port if the > Operating System is Linux Mandriva 2007 (kernel version 2.6.17-13mdv > ) or Linux Mandriva 2009. > I also tried the driver using? same java code (java class file of the > program I wrote), in Windows XP,? it does work. > > Should I configure something (special configuration in Linux)? or did I miss > something ? > I also have tested the latest RXTX 2.2pre2 driver, but it still have that > problem. > Hello Ferry This sounds like an unlikely problem. Even with USB dongle issues, I can't think of a reason that would be a problem. Is this a connection at 9600 8N1? Sometimes it really is the cable. -- Trent Jarvi tjarvi at qbang.org From ferry_new2004 at yahoo.com Mon Apr 13 22:15:04 2009 From: ferry_new2004 at yahoo.com (Ferry Sumendap) Date: Mon, 13 Apr 2009 21:15:04 -0700 (PDT) Subject: [Rxtx] Fw: In Linux, RXTX serial port lib cannot send character which hex is more than 127. Message-ID: <948418.50805.qm@web33103.mail.mud.yahoo.com> ----- Forwarded Message ---- From: Ferry Sumendap To: Trent Jarvi Sent: Tuesday, April 14, 2009 11:10:04 AM Subject: Re: [Rxtx] In Linux, RXTX serial port lib cannot send character which hex is more than 127. Thank you for your answer. I use the same machine, cable and devices to test. My PC is installed with Linux Mandriva and WINDOWS. The serial port physically have no problem since using Windows, it works. I also tested the serial port using MONI (tcl based program). MONI is linux based program to send some characters to serial port. Using MONI, I sent the characters to /dev/ttyS0, and it works because the device which is plugged in /dev/ttyS0 received and answered the message. But for RXTX, some how, java based program cannot send those characters. With the same java based program, it works properly in WINDOWS and the same cable, devices, hardware specification. That's why I am curious about RXTX. Here is the serial port configuration I used. Com Port /dev/ttyS0 Baud rate 19200 Data bits 8 ( value = 8) Stop bits 1 ( value = 1) Parity None ( value = 0) Thank you very much for your response. Regards, Ferry ________________________________ From: Trent Jarvi To: Ferry Sumendap Cc: rxtx at qbang.org Sent: Tuesday, April 14, 2009 11:01:04 AM Subject: Re: [Rxtx] In Linux, RXTX serial port lib cannot send character which hex is more than 127. On Mon, 13 Apr 2009, Ferry Sumendap wrote: > Hello everybody, > > I have just tested the RXTXserial port library version RXTX2-1-7pre20 to > send two characters which are character ascii 230 and 234. It seems that > the driver somehow did not send the two characters into serial port if the > Operating System is Linux Mandriva 2007 (kernel version 2.6.17-13mdv > ) or Linux Mandriva 2009. > I also tried the driver using same java code (java class file of the > program I wrote), in Windows XP, it does work. > > Should I configure something (special configuration in Linux) or did I miss > something ? > I also have tested the latest RXTX 2.2pre2 driver, but it still have that > problem. > Hello Ferry This sounds like an unlikely problem. Even with USB dongle issues, I can't think of a reason that would be a problem. Is this a connection at 9600 8N1? Sometimes it really is the cable. -- Trent Jarvi tjarvi at qbang.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090413/27a37ea5/attachment.html From ferry_new2004 at yahoo.com Mon Apr 13 22:23:53 2009 From: ferry_new2004 at yahoo.com (Ferry Sumendap) Date: Mon, 13 Apr 2009 21:23:53 -0700 (PDT) Subject: [Rxtx] In Linux, RXTX serial port lib cannot send character which hex is more than 127. In-Reply-To: References: <30875.39589.qm@web33106.mail.mud.yahoo.com> <81465.86461.qm@web33102.mail.mud.yahoo.com> Message-ID: <736778.48214.qm@web33108.mail.mud.yahoo.com> I am sorry not telling you about the configuration.. Yes I did test using the same serial port configuration, but the RXTX did not work properly. I also use "root" just in case there is security violation. If I sent another character that is below 127 (ascii < 127) the RXTX works properly either in LINUX or WINDOWS. I also cannot believe that coders of RXTX would make diffentiation between baudrate 19200 and 9600. The driver actually works very good unfortunately if the character is upper than ascii 127 (like ascii 230 and 234) it will not work. Thank you very much. Regards, Ferry ________________________________ From: Trent Jarvi To: Ferry Sumendap Cc: Trent Jarvi Sent: Tuesday, April 14, 2009 11:16:34 AM Subject: Re: [Rxtx] In Linux, RXTX serial port lib cannot send character which hex is more than 127. Hi Ferry, The only thing you mention that is not tested on a regular basis is the 19200 baudrate. There is nothing special (code wise) about that baudrate. On Mon, 13 Apr 2009, Ferry Sumendap wrote: > Thank you for your answer. > > I use the same machine, cable and devices to test. > My PC is installed with Linux Mandriva and WINDOWS. > The serial port physically have no problem since using Windows, it works. > > I also tested the serial port using MONI (tcl based program). > MONI is linux based program to send some characters to serial port. > Using MONI, I sent the characters to /dev/ttyS0, and it works because the > device which is plugged in /dev/ttyS0 received and answered the message. > > But for RXTX, some how, java based program cannot send those characters. > With the same java based program, it works properly in WINDOWS and the same > cable, devices, hardware specification. > That's why I am curious about RXTX. > > > > Here is the serial port configuration I used. > > Com Port /dev/ttyS0 > Baud rate 19200 > Data bits 8 ( value = 8) > Stop bits 1 ( value = 1) > Parity None ( value = 0) > > > > Thank you very much for your response. > > Regards, > Ferry > > > ____________________________________________________________________________ > From: Trent Jarvi > To: Ferry Sumendap > Cc: rxtx at qbang.org > Sent: Tuesday, April 14, 2009 11:01:04 AM > Subject: Re: [Rxtx] In Linux, RXTX serial port lib cannot send character > which hex is more than 127. > > > > On Mon, 13 Apr 2009, Ferry Sumendap wrote: > > > Hello everybody, > > > > I have just tested the RXTXserial port library version RXTX2-1-7pre20 to > > send two characters which are character ascii 230 and 234. It seems that > > the driver somehow did not send the two characters into serial port if the > > Operating System is Linux Mandriva 2007 (kernel version 2.6.17-13mdv > > ) or Linux Mandriva 2009. > > I also tried the driver using same java code (java class file of the > > program I wrote), in Windows XP, it does work. > > > > Should I configure something (special configuration in Linux) or did I > miss > > something ? > > I also have tested the latest RXTX 2.2pre2 driver, but it still have that > > problem. > > > > Hello Ferry > > This sounds like an unlikely problem. > > Even with USB dongle issues, I can't think of a reason that would be a > problem. Is this a connection at 9600 8N1? > > Sometimes it really is the cable. > > -- > Trent Jarvi > tjarvi at qbang.org > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090413/7a2fd5a0/attachment-0001.html From tjarvi at qbang.org Mon Apr 13 22:45:09 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 13 Apr 2009 22:45:09 -0600 (MDT) Subject: [Rxtx] In Linux, RXTX serial port lib cannot send character which hex is more than 127. In-Reply-To: <736778.48214.qm@web33108.mail.mud.yahoo.com> References: <30875.39589.qm@web33106.mail.mud.yahoo.com> <81465.86461.qm@web33102.mail.mud.yahoo.com> <736778.48214.qm@web33108.mail.mud.yahoo.com> Message-ID: This sounds like a signed vs unsigned char issue. Given that rxtx does binary read and write fine on Linux, I'm at a loss of what your problem may be. No, I don't suspect the baudrate is an issue either. On Mon, 13 Apr 2009, Ferry Sumendap wrote: > I am sorry not telling you about the configuration.. > > Yes I did test using the same serial port configuration, but the RXTX did > not work properly. > I also use "root" just in case there is security violation. > If? I sent another character that is below 127 (ascii < 127) the RXTX works > properly either in LINUX or WINDOWS. > > I also cannot believe that coders of RXTX would make diffentiation between > baudrate 19200 and 9600. > The driver actually works very good unfortunately if the character is upper > than ascii 127 (like ascii 230 and 234) it will not work. > > Thank you very much. > Regards, > > Ferry > > ____________________________________________________________________________ > From: Trent Jarvi > To: Ferry Sumendap > Cc: Trent Jarvi > Sent: Tuesday, April 14, 2009 11:16:34 AM > Subject: Re: [Rxtx] In Linux, RXTX serial port lib cannot send character > which hex is more than 127. > > > Hi Ferry, > > The only thing you mention that is not tested on a regular basis is the > 19200 baudrate.? There is nothing special (code wise) about that baudrate. > > On Mon, 13 Apr 2009, Ferry Sumendap wrote: > > > Thank you for your answer. > > > > I use the same machine, cable and devices to test. > > My PC is installed with Linux Mandriva and WINDOWS. > > The serial port physically have no problem since using Windows, it works. > > > > I also tested the serial port using MONI (tcl based program). > > MONI is linux based program to send some characters to serial port. > > Using MONI, I sent the characters to /dev/ttyS0, and it works because the > > device which is plugged in /dev/ttyS0 received and answered the message. > > > > But for RXTX, some how, java based program cannot send those characters. > > With the same java based program, it works properly in WINDOWS and the > same > > cable, devices, hardware specification. > > That's why I am curious about RXTX. > > > > > > > > Here is the serial port configuration I used. > > > > Com Port /dev/ttyS0 > > Baud rate 19200 > > Data bits 8 ( value = 8) > > Stop bits 1?? ( value = 1) > > Parity None? ( value = 0) > > > > > > > > Thank you very much for your response. > > > > Regards, > > Ferry > > > > > >___________________________________________________________________________ > _ > > From: Trent Jarvi > > To: Ferry Sumendap > > Cc: rxtx at qbang.org > > Sent: Tuesday, April 14, 2009 11:01:04 AM > > Subject: Re: [Rxtx] In Linux, RXTX serial port lib cannot send character > > which hex is more than 127. > > > > > > > > On Mon, 13 Apr 2009, Ferry Sumendap wrote: > > > > > Hello everybody, > > > > > > I have just tested the RXTXserial port library version? RXTX2-1-7pre20 > to > > > send two characters which are character ascii? 230 and 234. It seems > that > > > the driver somehow did not send the two characters into serial port if > the > > > Operating System is Linux Mandriva 2007 (kernel version 2.6.17-13mdv > > > ) or Linux Mandriva 2009. > > > I also tried the driver using? same java code (java class file of the > > > program I wrote), in Windows XP,? it does work. > > > > > > Should I configure something (special configuration in Linux)? or did I > > miss > > > something ? > > > I also have tested the latest RXTX 2.2pre2 driver, but it still have > that > > > problem. > > > > > > > Hello Ferry > > > > This sounds like an unlikely problem. > > > > Even with USB dongle issues, I can't think of a reason that would be a > > problem.? Is this a connection at 9600 8N1? > > > > Sometimes it really is the cable. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > > > > > > > > From ilkka at myller.com Mon Apr 13 23:12:16 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 14 Apr 2009 08:12:16 +0300 Subject: [Rxtx] In Linux, RXTX serial port lib cannot send character which hex is more than 127. In-Reply-To: References: <30875.39589.qm@web33106.mail.mud.yahoo.com> <81465.86461.qm@web33102.mail.mud.yahoo.com> <736778.48214.qm@web33108.mail.mud.yahoo.com> Message-ID: Hi, Another suggestion: incorrect java byte casting. Java byte type has a range from -128 to 127. I've seen people assume range of 0 - 255. Incorrect integer casting with bytes is a common mistake is to cause those >127 ascii issues. Could it be? (int)b versus (int)(b & 0xFF) -- I Trent Jarvi kirjoitti 14.4.2009 kello 7.45: > > This sounds like a signed vs unsigned char issue. Given that rxtx > does binary read and write fine on Linux, I'm at a loss of what your > problem may be. > > No, I don't suspect the baudrate is an issue either. > > On Mon, 13 Apr 2009, Ferry Sumendap wrote: > >> I am sorry not telling you about the configuration.. >> Yes I did test using the same serial port configuration, but the >> RXTX did >> not work properly. >> I also use "root" just in case there is security violation. >> If I sent another character that is below 127 (ascii < 127) the >> RXTX works >> properly either in LINUX or WINDOWS. >> I also cannot believe that coders of RXTX would make diffentiation >> between >> baudrate 19200 and 9600. >> The driver actually works very good unfortunately if the character >> is upper >> than ascii 127 (like ascii 230 and 234) it will not work. >> Thank you very much. >> Regards, >> Ferry >> ____________________________________________________________________________ >> From: Trent Jarvi >> To: Ferry Sumendap >> Cc: Trent Jarvi >> Sent: Tuesday, April 14, 2009 11:16:34 AM >> Subject: Re: [Rxtx] In Linux, RXTX serial port lib cannot send >> character >> which hex is more than 127. >> Hi Ferry, >> The only thing you mention that is not tested on a regular basis is >> the >> 19200 baudrate. There is nothing special (code wise) about that >> baudrate. >> On Mon, 13 Apr 2009, Ferry Sumendap wrote: >> > Thank you for your answer. >> > >> > I use the same machine, cable and devices to test. >> > My PC is installed with Linux Mandriva and WINDOWS. >> > The serial port physically have no problem since using Windows, >> it works. >> > >> > I also tested the serial port using MONI (tcl based program). >> > MONI is linux based program to send some characters to serial port. >> > Using MONI, I sent the characters to /dev/ttyS0, and it works >> because the >> > device which is plugged in /dev/ttyS0 received and answered the >> message. >> > >> > But for RXTX, some how, java based program cannot send those >> characters. >> > With the same java based program, it works properly in WINDOWS >> and the >> same >> > cable, devices, hardware specification. >> > That's why I am curious about RXTX. >> > >> > >> > >> > Here is the serial port configuration I used. >> > >> > Com Port /dev/ttyS0 >> > Baud rate 19200 >> > Data bits 8 ( value = 8) >> > Stop bits 1 ( value = 1) >> > Parity None ( value = 0) >> > >> > >> > >> > Thank you very much for your response. >> > >> > Regards, >> > Ferry >> > >> > >> > >> ___________________________________________________________________________ >> _ >> > From: Trent Jarvi >> > To: Ferry Sumendap >> > Cc: rxtx at qbang.org >> > Sent: Tuesday, April 14, 2009 11:01:04 AM >> > Subject: Re: [Rxtx] In Linux, RXTX serial port lib cannot send >> character >> > which hex is more than 127. >> > >> > >> > >> > On Mon, 13 Apr 2009, Ferry Sumendap wrote: >> > >> > > Hello everybody, >> > > >> > > I have just tested the RXTXserial port library version >> RXTX2-1-7pre20 >> to >> > > send two characters which are character ascii 230 and 234. It >> seems >> that >> > > the driver somehow did not send the two characters into serial >> port if >> the >> > > Operating System is Linux Mandriva 2007 (kernel version >> 2.6.17-13mdv >> > > ) or Linux Mandriva 2009. >> > > I also tried the driver using same java code (java class file >> of the >> > > program I wrote), in Windows XP, it does work. >> > > >> > > Should I configure something (special configuration in Linux) >> or did I >> > miss >> > > something ? >> > > I also have tested the latest RXTX 2.2pre2 driver, but it still >> have >> that >> > > problem. >> > > >> > >> > Hello Ferry >> > >> > This sounds like an unlikely problem. >> > >> > Even with USB dongle issues, I can't think of a reason that would >> be a >> > problem. Is this a connection at 9600 8N1? >> > >> > Sometimes it really is the cable. >> > >> > -- >> > Trent Jarvi >> > tjarvi at qbang.org >> > >> > >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From sunil at saltriver.com Tue Apr 14 01:06:38 2009 From: sunil at saltriver.com (Sunil Bhambani) Date: Tue, 14 Apr 2009 07:06:38 -0000 Subject: [Rxtx] RxTx on Mac for USB Message-ID: <1080422816.3127.6.camel@localhost.localdomain> Hi, I have a GPS device which is USB device. I want to use that device on Mac System and Java as the programming language. I have read that USB support through RxTx on Mac is not there. Is this correct? I would like to read the data that comes to GPS device. Can some connector be used to communicate with that device. For example USB to RJ11 or USB to serial connector? Are this connectors reliable enough to be used? Hope to get the reply soon. -- Thank & Regards Sunil -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090414/295ccb1d/attachment.html From helgeingvart at gmail.com Tue Apr 14 01:43:04 2009 From: helgeingvart at gmail.com (Helge Fredriksen) Date: Tue, 14 Apr 2009 09:43:04 +0200 Subject: [Rxtx] IO exceptions on 2.2pre2 In-Reply-To: References: <306B677E-9207-44CB-81CD-787A50DB7DA6@myller.com> Message-ID: FYI: There seem to be success on this problem by switching to your commercial counterpart from SerialIO (http://www.serialio.com). A FTDI only problem? Best regards, Helge Fredriksen On Sat, Mar 28, 2009 at 5:32 PM, Helge Fredriksen wrote: > Thanks for your suggestions, > > We have tried switching off the power saving settings as recommended, but > regrettably we see the same things happening still. > > The FTDI device is not connected directly to USB hubs, no. > > Someone have any more ideas? > > Best regards, > Helge Fredriksen > > > On Tue, Mar 24, 2009 at 9:27 AM, Ilkka Myller wrote: > >> Hi Helge, >> >> I am not sure if this will help, but you could try this: >> >> echo on > /sys/bus/usb/devices//power/level >> echo 0 > /sys/bus/usb/devices//power/autosuspend >> >> is the USB-bus device id of your FTDI adapter (bus-device, for >> example "2-2") >> >> This will disable USB power saving/autosuspend of FTDI USB-device. >> I've seen some some systems where this helps with FTDI-adapter connection >> drops. >> >> Also: is your FTDI device directly connected to PC's USB root hub? If not, >> test that too. >> >> >> -- >> I >> >> (replace with the usb bus device id of your FTDI serial >> adapter) >> >> Helge Fredriksen kirjoitti 24.3.2009 kello 9.45: >> >> Hello! >> >> Here's the device details: >> >> FT232R is a USB to serial UART interface. >> >> Link to componentt: http://www.ftdichip.com/Products/FT232R.htm >> >> Regards, >> Helge Fredriksen >> >> On Tue, Mar 24, 2009 at 12:05 AM, Trent Jarvi wrote: >> >>> >>> >>> On Mon, 23 Mar 2009, Helge Fredriksen wrote: >>> >>> Hello again. >>>> >>>> I'm having a bit trouble with the 2.2pre2 version it seems. I'm having >>>> an >>>> application running on Ubuntu 8.10 that seem to run stable but after an >>>> hour >>>> or so the application breaks down with lot's of IO exceptions like this: >>>> >>>> java.io.IOException: Input/output error in nativeavailable >>>> at gnu.io.RXTXPort.nativeavailable(Native Method) >>>> at gnu.io.RXTXPort$SerialInputStream.available(RXTXPort.java:1596) >>>> >>>> atcom.poseidon.usb.UsbInterface$MySerialPortEventListener.serialEvent(UsbInte >>>> rface.java:251) >>>> at gnu.io.RXTXPort.sendEvent(RXTXPort.java:772) >>>> at gnu.io.RXTXPort.eventLoop(Native Method) >>>> at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1641) >>>> >>>> Any ideas? >>>> >>> >>> Hi Helge, >>> >>> It sounds like the file descriptor (USB driver) is in an invalid state. >>> >>> What can you tell us about the USB dongle? Is it bluetooth? Do you know >>> what chipset is in it? >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090414/e2c97c4f/attachment.html From Steffen.DETTMER at ingenico.com Tue Apr 14 02:21:35 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 14 Apr 2009 10:21:35 +0200 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49E3F7D0.5090207@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49E3B6E3.5050203@cox.net> <49E3F7D0.5090207@bbs.darktech.org> Message-ID: <20090414082135.GG5090@elberon.bln.de.ingenico.com> * cowwoc wrote on Mon, Apr 13, 2009 at 22:41 -0400: > Gregg Wonderly wrote: > > The real issue is that you have to understand that > > the on the Sun JVM, the GC can run finalization or advertise a dropped > > reference before an object is actually unreferenced in some cases. > > I've never seen this myself. Can you reproduce it on the latest JRE? If > so, this sounds like a bug to me and should be fixed. Please consider > filing a bug report and telling me the bug number. I'll try running it > by my Sun contacts. I found some general hints here: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2261.html Traditional finalization in garbage collected languages is defined in terms of object reachability. But objects can easily become "unreachable" earlier than the programmer expects, due to compiler optimizations. An object may be logically in use long past the last point at which the memory associated with the object is accessed or referenced by any pointers visible to the garbage collector. In the worst case, the compiler might decide to store all the fields of an object in registers, and then observe that the "this" pointer for the newly allocated memory is dead immediately after the allocation, and hence not save it anywhere. The garbage collector, even if run immediately after the allocation, would then discover that the memory object is no longer reachable, and run the finalizer immediately, in spite of the fact that the object fields are still in use, and in fact may remain in use after the finalizer has run. However, if this would be a so general weakness that someone is adviced to store object instances in collections instead of using members or having the references on the stack - even if used correctly - I think it would be a major weakness which probably had been fixed, because otherwise raping collections as such workarounds would be commonly visible. BTW, I think the citation above is wrong if the optimised member values are used after that. The destructor / finalizer may set all fields to null or so and (ordinary) optimizers should not affect the behavior of correct and usual code I think. (ohh, and Cowwoc, forced-GC and to forbid the developer to control lifecycle in Java is considered a feature, not a bug! -- SCNR) oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From michael.erskine at ketech.com Tue Apr 14 02:50:53 2009 From: michael.erskine at ketech.com (Michael Erskine) Date: Tue, 14 Apr 2009 09:50:53 +0100 Subject: [Rxtx] Wiki Spam pages - need of captcha? In-Reply-To: References: Message-ID: <06BA3262D918014F9183B66425D5A8D45FA42D88FB@no-sv-03.ketech.local> All, See http://tech.slashdot.org/article.pl?sid=09/04/13/0120226 for details of this particular use of open wiki sites and the apology. Regards, Michael Erskine. From Steffen.DETTMER at ingenico.com Tue Apr 14 04:27:53 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 14 Apr 2009 12:27:53 +0200 Subject: [Rxtx] In Linux, RXTX serial port lib cannot send character which hex is more than 127. In-Reply-To: <30875.39589.qm@web33106.mail.mud.yahoo.com> References: <30875.39589.qm@web33106.mail.mud.yahoo.com> Message-ID: <20090414102753.GI5090@elberon.bln.de.ingenico.com> * Ferry Sumendap wrote on Mon, Apr 13, 2009 at 20:24 -0700: > I have just tested the RXTXserial port library version > RXTX2-1-7pre20 to send two characters which are character ascii > 230 and 234. Can you send -26 and -22 instead? Then it probably is a casting issue (as Trent and Ilkka already considered). oki, Steffen End of message. ------------------------------------------------------------------->8======= About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From cowwoc at bbs.darktech.org Wed Apr 1 22:05:13 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Thu, 02 Apr 2009 00:05:13 -0400 Subject: [Rxtx] Windows 64-bit support? Message-ID: <49D43979.4050702@bbs.darktech.org> Hi, I'd like to run RXTX under the Windows 64-bit JVM. Are there plans to release an official 64-bit version anytime soon? Gili From bill7007 at gmail.com Thu Apr 2 16:01:17 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Thu, 2 Apr 2009 18:01:17 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel Message-ID: Hi, I have an rxtx serial application that used to work reliably until I had to move it to newer hardware and kernel. Now, the application sometimes hangs near first port use. When it does hang, it can be released by starting a second copy of the application which is locked out of the ports but does release the first process. Upgraded from rxtx-2.1-7-r2 to rxtx-2.2pre2 but still hangs. Tried to rebuild on the target machine and ran into the 'UTS_RELEASE' undeclared problem so holding on that approach. Recompiled OK on a 2.6.9-42.0.3.ELsmp system. Debug messages were turned on using: "./configure --enable-DEBUG" and modified RXTXPort.java with: "debug = true;" "z = new Zystem(Zystem.PRINT_MODE);" Below is capture of the application with debugging enabled. It show the application hang point, and the second application's printout at the release point. (pre3 is the locally modified version of pre2) Any suggestions on how to pin this down further? Thanks, +BillJ $ java -version java version "1.5.0_06" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05) Java HotSpot(TM) Client VM (build 1.5.0_06-b05, mixed mode, sharing) $ uname -a Linux qms4 2.6.18-92.1.6.el5 #1 SMP Wed Jun 25 13:49:24 EDT 2008 i686 i686 i386 GNU/Linux ***CAPTURE: [qms at qms4 ~]$ ./qms/ScriptFiles/startup.sh Thu Apr 02 13:35:45 EDT 2009:Setting Log File to:/home/qms/qms/QMS.log Thu Apr 02 13:35:45 EDT 2009:TSettings.HandleIni:ReUsing Ini file:/home/qms/qms/qms.properties WARNING: RXTX Version mismatch Jar version = RXTX-2.2pre2 native lib Version = RXTX-2.2pre3 fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB2 fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB1 fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB0 fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile RXTXPort {} RXTX WARNING: This library was compiled to run with OS release 2.4.20 and you are currently running OS release 2.6.18-92.1.6.el5. In some cases this can be a problem. Try recompiling RXTX if you notice strange behavior. If you just compiled RXTX make sure /usr/include/linux is a symbolic link to the include files that came with the kernel source and not an older copy. press enter to continue RXTXPort:RXTXPort(/dev/ttyUSB2) called fhs_lock: creating lockfile: 10127 open: locking worked for /dev/ttyUSB2 open: fd returned is 8 RXTXPort:MontitorThread:MonitorThread() RXTXPort:MontitorThread:run() has_line_status_register_acess: Port does not support TIOCSERGETLSR init_threads: get eis init_threads: set eis init_threads: stop RXTXPort:RXTXPort(/dev/ttyUSB2) returns with fd = 8 RXTXPort:setSerialPortParams(38400 8 1 0) called RXTXPort:setSerialPortParams(38400 8 1 0) returning RXTXPort:getInputStream() called and returning Thu Apr 02 13:36:02 EDT 2009:TSerial[22]:Using Port:/dev/ttyUSB2 RXTXPort:getOutputStream() called and returning Thu Apr 02 13:36:02 EDT 2009:TSerial[22].Transmit:TN Entering RXTXPort:SerialOutputStream:write(4) writeArray() Leaving RXTXPort:SerialOutputStream:write(4) RXTXPort:SerialOutputStream:flush() enter RXTXPort:SerialOutputStream:flush() leave Thu Apr 02 13:36:02 EDT 2009:TSerial[22].Transmit:RV Entering RXTXPort:SerialOutputStream:write(4) writeArray() Leaving RXTXPort:SerialOutputStream:write(4) RXTXPort:SerialOutputStream:flush() enter RXTXPort:SerialInputStream:read(8192 0 8192) called ***FIRST PROCESS HANGS HERE ***THEN PROCEEDS AFTER SECOND PROCESS STARTS RXTXPort:SerialOutputStream:flush() leave Thu Apr 02 13:41:29 EDT 2009:TSerial[22].Transmit:IH9 Entering RXTXPort:SerialOutputStream:write(5) writeArray() Leaving RXTXPort:SerialOutputStream:write(5) RXTXPort:SerialOutputStream:flush() enter RXTXPort:SerialOutputStream:flush() leave Thu Apr 02 13:41:29 EDT 2009:TSerial[22].Transmit:IL11 ***END CAPTURE ***CAPTURE SECOND PROCESS FAILS OPEN [qms at qms4 ~]$ ./qms/ScriptFiles/startup.sh Thu Apr 02 13:41:27 EDT 2009:Setting Log File to:/home/qms/qms/QMS.log Thu Apr 02 13:41:27 EDT 2009:TSettings.HandleIni:ReUsing Ini file:/home/qms/qms/qms.properties WARNING: RXTX Version mismatch Jar version = RXTX-2.2pre2 native lib Version = RXTX-2.2pre3 fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB2: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB1: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB0: File exists fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB2: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB1: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB0: File exists fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile Thu Apr 02 13:41:30 EDT 2009:TIOBoard: java.io.IOException: java.io.IOException: TSerial[22]: Open Failed ***END CAPTURE -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090402/c66f8d70/attachment-0013.html From netbeans at gatworks.com Thu Apr 2 17:15:04 2009 From: netbeans at gatworks.com (U. George) Date: Thu, 02 Apr 2009 19:15:04 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: Message-ID: <49D546F8.20807@gatworks.com> > "z = new Zystem(Zystem.PRINT_MODE);" > Below is capture of the application with debugging enabled. It show > the application hang point, and the second application's printout at the > release point. (pre3 is the locally modified version of pre2) > Any suggestions on how to pin this down further? > Thanks, > +BillJ When perceived runability is hung, try a ^\ ( control \) on console. This gets the JVM to dump the stacks of all the java threads. If you know the thread that is stuck, then u can see what java statement its stuck at. From tjarvi at qbang.org Thu Apr 2 19:25:17 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 2 Apr 2009 19:25:17 -0600 (MDT) Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: <49D546F8.20807@gatworks.com> References: <49D546F8.20807@gatworks.com> Message-ID: On Thu, 2 Apr 2009, U. George wrote: >> "z = new Zystem(Zystem.PRINT_MODE);" >> Below is capture of the application with debugging enabled. It show >> the application hang point, and the second application's printout at the >> release point. (pre3 is the locally modified version of pre2) >> Any suggestions on how to pin this down further? >> Thanks, >> +BillJ > > When perceived runability is hung, try a ^\ ( control \) on console. > This gets the JVM to dump the stacks of all the java threads. > If you know the thread that is stuck, then u can see what java statement > its stuck at. I've also noticed some linux systems hanging with open/read/write and saw kacpid storms. I need to look at it more but did observe kacpid consuming a core and not returning to a normal state for a significant period of time. It was easy to observe from top sorted by CPU usage. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Apr 2 19:26:18 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 2 Apr 2009 19:26:18 -0600 (MDT) Subject: [Rxtx] Windows 64-bit support? In-Reply-To: <49D43979.4050702@bbs.darktech.org> References: <49D43979.4050702@bbs.darktech.org> Message-ID: On Thu, 2 Apr 2009, cowwoc wrote: > Hi, > > I'd like to run RXTX under the Windows 64-bit JVM. Are there plans > to release an official 64-bit version anytime soon? > It is in the prerelease and will be in the final release. I'm pushing it through as fast as I can in my free time. -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Thu Apr 2 22:57:34 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Fri, 03 Apr 2009 00:57:34 -0400 Subject: [Rxtx] Missing documentation In-Reply-To: References: <49D43979.4050702@bbs.darktech.org> Message-ID: <49D5973E.4050400@bbs.darktech.org> Hi, I noticed that RXTX 2.1 drops javax.comm support in favor of gnu.io. I have one major problem with this: the gui.io.* documentation is very poor. Many classes and methods have no Javadoc at all which makes them difficult to use. Please fix this for the final release. Thank you, Gili From alex.sas at freemail.hu Fri Apr 3 01:36:54 2009 From: alex.sas at freemail.hu (Sas Alex) Date: Fri, 3 Apr 2009 09:36:54 +0200 (CEST) Subject: [Rxtx] Serial port false reads Message-ID: Hi all, On Windows XP, using rxtx-2.1-7-r2 I have a program communicating on a serial line like the following (excerpt): { os.write(command); os.flush(); // Thread.sleep(period); // read response while(is.available() > 0) { is.read() } } If there is a sleep between the os.flush and the reading cycle the correct answer is received. Otherwise (sometimes) there are extra, erronous characters at the beginning of the answer, but the correct answer (according to the protocol) also arrives, afterwards. Is this a normal behaviour, one should wait before the read? If yes, is there a way to determine the minimum amount of time to wait for? Serial port params are: 9600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE. Thank you in advance, Alex ________________________________________________________ El?foglal?si akci? meghosszabb?tva! Korfui ?d?l?s m?r 56.910 Ft-t?l. http://www.budavartours.hu/gorogorszag/?utm_campaign=origo&utm_source=freemail_kimeno_090403&utm_medium=ct&utm_content=korfu_elofoglalasi_akcio#reg_Korfu -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090403/8f3650ea/attachment-0013.html From bill7007 at gmail.com Fri Apr 3 16:15:30 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Fri, 3 Apr 2009 18:15:30 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: <49D546F8.20807@gatworks.com> Message-ID: > When perceived runability is hung, try a ^\ ( control \) on console. >> This gets the JVM to dump the stacks of all the java threads. > > Good idea... A thread dump is below, it looks like only some system threads are in wait state which is probably normal. The "main" thread is stopped writing the first data out the serial port which should complete but its has stopped at: at gnu.io.RXTXPort.nativeDrain(Native Method) It show its state as runnable though. There is another thread, "SerialReader_22", that is waiting to read any data on the same port. I'll bring the app up under Netbeans debugger next. >> > I've also noticed some linux systems hanging with open/read/write and saw > kacpid storms. No CPU use going when it hangs, acts like a deadlock. THREAD DUMP AT HANG: Entering RXTXPort:SerialOutputStream:write(4) writeArray() Leaving RXTXPort:SerialOutputStream:write(4) RXTXPort:SerialOutputStream:flush() enter RXTXPort:SerialInputStream:read(8192 0 8192) called Full thread dump Java HotSpot(TM) Client VM (1.5.0_06-b05 mixed mode, sharing): "SerialReader_22" daemon prio=1 tid=0x087abf38 nid=0x3c8b runnable [0xb1a43000..0xb1a43f30] at gnu.io.RXTXPort.readArray(Native Method) at gnu.io.RXTXPort$SerialInputStream.read(RXTXPort.java:1454) - locked <0x88ca55b8> (a gnu.io.RXTXPort$SerialInputStream) at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:411) at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) - locked <0x88cab378> (a java.io.InputStreamReader) at java.io.InputStreamReader.read(InputStreamReader.java:167) at java.io.BufferedReader.fill(BufferedReader.java:136) at java.io.BufferedReader.readLine(BufferedReader.java:299) - locked <0x88cab378> (a java.io.InputStreamReader) at java.io.BufferedReader.readLine(BufferedReader.java:362) at qms.TSerialPort$SerialRead.run(TSerialPort.java:268) at java.lang.Thread.run(Thread.java:595) "Thread-1" prio=1 tid=0x08a43360 nid=0x3c8a runnable [0xb1ac4000..0xb1ac4db0] at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1641) "AWT-XAWT" daemon prio=1 tid=0x08acc848 nid=0x3c87 runnable [0xb1b45000..0xb1b45e30] at sun.awt.X11.XToolkit.waitForEvents(Native Method) at sun.awt.X11.XToolkit.run(XToolkit.java:463) at sun.awt.X11.XToolkit.run(XToolkit.java:438) at java.lang.Thread.run(Thread.java:595) "Java2D Disposer" daemon prio=1 tid=0x08ab9d30 nid=0x3c86 in Object.wait() [0xb1bc6000..0xb1bc70b0] at java.lang.Object.wait(Native Method) - waiting on <0x8917b110> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:116) - locked <0x8917b110> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:132) at sun.java2d.Disposer.run(Disposer.java:107) at java.lang.Thread.run(Thread.java:595) "Low Memory Detector" daemon prio=1 tid=0x087bea68 nid=0x3c84 runnable [0x00000000..0x00000000] "CompilerThread0" daemon prio=1 tid=0x087bd4c0 nid=0x3c83 waiting on condition [0x00000000..0xb23a7a18] "Signal Dispatcher" daemon prio=1 tid=0x087bc520 nid=0x3c82 runnable [0x00000000..0x00000000] "Finalizer" daemon prio=1 tid=0x087b5710 nid=0x3c81 in Object.wait() [0xb26a9000..0xb26a9f30] at java.lang.Object.wait(Native Method) - waiting on <0x8914a770> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:116) - locked <0x8914a770> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:132) at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159) "Reference Handler" daemon prio=1 tid=0x087b49c8 nid=0x3c80 in Object.wait() [0xb272a000..0xb272adb0] at java.lang.Object.wait(Native Method) - waiting on <0x8914a7f0> (a java.lang.ref.Reference$Lock) at java.lang.Object.wait(Object.java:474) at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116) - locked <0x8914a7f0> (a java.lang.ref.Reference$Lock) "main" prio=1 tid=0x08777b88 nid=0x3c7e runnable [0xbffa7000..0xbffa74f8] at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1248) at qms.TSerialPort.Transmit(TSerialPort.java:192) - locked <0x88c99a68> (a qms.TSerialPort) at qms.TIOBoard.GetIOBoardVersion(TIOBoard.java:168) at qms.TIOBoard.(TIOBoard.java:73) at qms.TQMS.(TQMS.java:47) at qms.MainForm.(MainForm.java:2076) at qms.MainForm.main(MainForm.java:2099) "VM Thread" prio=1 tid=0x087b1e20 nid=0x3c7f runnable "VM Periodic Task Thread" prio=1 tid=0x087bff50 nid=0x3c85 waiting on condition -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090403/20b7bca4/attachment-0012.html From Martin.Oberhuber at windriver.com Fri Apr 3 16:23:43 2009 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Sat, 4 Apr 2009 00:23:43 +0200 Subject: [Rxtx] Missing documentation In-Reply-To: <49D5973E.4050400@bbs.darktech.org> References: <49D43979.4050702@bbs.darktech.org> <49D5973E.4050400@bbs.darktech.org> Message-ID: <460801A4097E3D4CA04CC64EE648584809C8BD6F@ism-mail03.corp.ad.wrs.com> Hello Gili, The classes in the gnu.io namespace are designed to work exactly as their counterparts in the javax.comm namespace. Therefore, if you just take the javax.comm Javadocs that's what you want. Unfortunately I don't think we can just copy & paste the javax.comm Javadocs into RXTX due to license restrictions. I guess that's the main reason why RXTX is not (yet) Javadoc'd as extensively as it should be. Actually, writing Javadocs from scratch WITHOUT referencing the wording of the Sun Javadocs is not that easy. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of cowwoc > Sent: Freitag, 03. April 2009 06:58 > To: rxtx at qbang.org > Subject: [Rxtx] Missing documentation > > Hi, > > I noticed that RXTX 2.1 drops javax.comm support in favor > of gnu.io. > I have one major problem with this: the gui.io.* > documentation is very > poor. Many classes and methods have no Javadoc at all which > makes them > difficult to use. Please fix this for the final release. > > Thank you, > Gili > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Fri Apr 3 16:54:50 2009 From: netbeans at gatworks.com (U. George) Date: Fri, 03 Apr 2009 18:54:50 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: <49D546F8.20807@gatworks.com> Message-ID: <49D693BA.8060909@gatworks.com> I would have tried 2 or 3 "^\" . If things are stuck, then all will be at same 'java' instruction. If thread is moving, then one of the snapshots would be different. I *think* flushing/draining wont return until the kernel buffers to device have been accepted by device. Stuck/paused device? Bill Johnson wrote: > > > > > When perceived runability is hung, try a ^\ ( control \) on console. > This gets the JVM to dump the stacks of all the java threads. > > > Good idea... A thread dump is below, it looks like only some system > threads are in wait state which is prob From cowwoc at bbs.darktech.org Fri Apr 3 17:45:09 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Fri, 03 Apr 2009 19:45:09 -0400 Subject: [Rxtx] Missing documentation In-Reply-To: <460801A4097E3D4CA04CC64EE648584809C8BD6F@ism-mail03.corp.ad.wrs.com> References: <49D43979.4050702@bbs.darktech.org> <49D5973E.4050400@bbs.darktech.org> <460801A4097E3D4CA04CC64EE648584809C8BD6F@ism-mail03.corp.ad.wrs.com> Message-ID: <49D69F85.3030804@bbs.darktech.org> You could always send Sun a formal email and ask for permission to copy their Javadoc. I doubt they would give you problems. Gili Oberhuber, Martin wrote: > Hello Gili, > > The classes in the gnu.io namespace are designed to work exactly > as their counterparts in the javax.comm namespace. Therefore, > if you just take the javax.comm Javadocs that's what you want. > > Unfortunately I don't think we can just copy & paste the > javax.comm Javadocs into RXTX due to license restrictions. > > I guess that's the main reason why RXTX is not (yet) Javadoc'd > as extensively as it should be. Actually, writing Javadocs > from scratch WITHOUT referencing the wording of the Sun > Javadocs is not that easy. > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] >> On Behalf Of cowwoc >> Sent: Freitag, 03. April 2009 06:58 >> To: rxtx at qbang.org >> Subject: [Rxtx] Missing documentation >> >> Hi, >> >> I noticed that RXTX 2.1 drops javax.comm support in favor >> of gnu.io. >> I have one major problem with this: the gui.io.* >> documentation is very >> poor. Many classes and methods have no Javadoc at all which >> makes them >> difficult to use. Please fix this for the final release. >> >> Thank you, >> Gili >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> From cowwoc at bbs.darktech.org Sat Apr 4 15:13:38 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sat, 04 Apr 2009 17:13:38 -0400 Subject: [Rxtx] Java5 support Message-ID: <49D7CD82.1040904@bbs.darktech.org> Now that you dropped javax.comm support, how about improving the API by replacing Enumation by Iterator, int by enum, and using Generics? It would improve the usability of the API. Gili From cowwoc at bbs.darktech.org Sat Apr 4 16:12:13 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sat, 04 Apr 2009 18:12:13 -0400 Subject: [Rxtx] RXTX Version mismatch in 2.2pre2 Message-ID: <49D7DB3D.5040008@bbs.darktech.org> When using RXTX-2.2pre2 I always get the following message: WARNING: RXTX Version mismatch Jar version = RXTX-2.2pre1 native lib Version = RXTX-2.2pre2 I have double checked that I am using the correct Jar file. Is this a known bug in pre2? Gili From tjarvi at qbang.org Sat Apr 4 16:48:53 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Apr 2009 16:48:53 -0600 (MDT) Subject: [Rxtx] RXTX Version mismatch in 2.2pre2 In-Reply-To: <49D7DB3D.5040008@bbs.darktech.org> References: <49D7DB3D.5040008@bbs.darktech.org> Message-ID: > When using RXTX-2.2pre2 I always get the following message: > > WARNING: RXTX Version mismatch > Jar version = RXTX-2.2pre1 > native lib Version = RXTX-2.2pre2 > Yep. You should still be able to test it. -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Sat Apr 4 16:50:43 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sat, 04 Apr 2009 18:50:43 -0400 Subject: [Rxtx] RXTX Version mismatch in 2.2pre2 In-Reply-To: References: <49D7DB3D.5040008@bbs.darktech.org> Message-ID: <49D7E443.9070404@bbs.darktech.org> In other words this is a known bug that will be fixed in the final version? Gili Trent Jarvi wrote: > > >> When using RXTX-2.2pre2 I always get the following message: >> >> WARNING: RXTX Version mismatch >> Jar version = RXTX-2.2pre1 >> native lib Version = RXTX-2.2pre2 >> > > Yep. > > You should still be able to test it. > > -- > Trent Jarvi > tjarvi at qbang.org From cowwoc at bbs.darktech.org Sat Apr 4 16:57:34 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sat, 04 Apr 2009 18:57:34 -0400 Subject: [Rxtx] IOException: Underlying input stream returned zero bytes Message-ID: <49D7E5DE.2050405@bbs.darktech.org> Hi, There seems to be a bug in RXTX 2.2pre2's handling of InputStream timeouts. If you open a serial port without ever invoking enableReceiveTimeout() then invoking InputStream.read() will always return 0 bytes right away. If you wrap the InputStream and invoke BufferedReader.readline() you will get the following exception: java.io.IOException: Underlying input stream returned zero bytes at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:268) [na:1.6.0_14-ea] at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:306) [na:1.6.0_14-ea] at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:158) [na:1.6.0_14-ea] at java.io.InputStreamReader.read(InputStreamReader.java:167) [na:1.6.0_14-ea] at java.io.BufferedReader.fill(BufferedReader.java:136) [na:1.6.0_14-ea] at java.io.BufferedReader.readLine(BufferedReader.java:299) [na:1.6.0_14-ea] at java.io.BufferedReader.readLine(BufferedReader.java:362) [na:1.6.0_14-ea] [snip] If you enable a timeout, the exception will only occur after the timeout expires. In short, it looks like RXTX is using a default timeout of zero (I am expecting it to block forever). It looks like other people have run into this as well: http://forums.sun.com/thread.jspa?threadID=5165346&start=10&tstart=0 Please confirm whether this is a known bug. Thank you, Gili From tjarvi at qbang.org Sat Apr 4 17:27:19 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Apr 2009 17:27:19 -0600 (MDT) Subject: [Rxtx] IOException: Underlying input stream returned zero bytes In-Reply-To: <49D7E5DE.2050405@bbs.darktech.org> References: <49D7E5DE.2050405@bbs.darktech.org> Message-ID: On Sat, 4 Apr 2009, cowwoc wrote: > Hi, > > There seems to be a bug in RXTX 2.2pre2's handling of InputStream > timeouts. If you open a serial port without ever invoking > enableReceiveTimeout() then invoking InputStream.read() will always > return 0 bytes right away. If you wrap the InputStream and invoke > BufferedReader.readline() you will get the following exception: > > java.io.IOException: Underlying input stream returned zero bytes > at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:268) > [na:1.6.0_14-ea] > at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:306) > [na:1.6.0_14-ea] > at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:158) > [na:1.6.0_14-ea] > at java.io.InputStreamReader.read(InputStreamReader.java:167) > [na:1.6.0_14-ea] > at java.io.BufferedReader.fill(BufferedReader.java:136) > [na:1.6.0_14-ea] > at java.io.BufferedReader.readLine(BufferedReader.java:299) > [na:1.6.0_14-ea] > at java.io.BufferedReader.readLine(BufferedReader.java:362) > [na:1.6.0_14-ea] > [snip] > > If you enable a timeout, the exception will only occur after the > timeout expires. In short, it looks like RXTX is using a default timeout > of zero (I am expecting it to block forever). It looks like other people > have run into this as well: > http://forums.sun.com/thread.jspa?threadID=5165346&start=10&tstart=0 > > Please confirm whether this is a known bug. > Hi Gili I've known about it but was not sure if it was a bug or not. It looks like we can treat it as a bug if nio is throwing an exception. Timeout and Thresholds are well documented in javax.comm but I didn't recall seeing defaults. For that reason, I've encouraged people to set the threshold and timeout to what they expect. Another note about InputStream.read(void): I noticed that I don't use that function at all while looking at code coverage results. Keep your eye out for additional issues. -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Sat Apr 4 19:03:29 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sat, 04 Apr 2009 21:03:29 -0400 Subject: [Rxtx] IOException: Underlying input stream returned zero bytes In-Reply-To: References: <49D7E5DE.2050405@bbs.darktech.org> Message-ID: <49D80361.7020801@bbs.darktech.org> Trent Jarvi wrote: > For that reason, I've encouraged people to set the threshold and timeout > to what they expect. It doesn't help. There doesn't seem to be a way to disable the timeout, even if you invoke disableReceiveTimeout() explicitly. Let me know when you put in a fix and I will test it. Thanks, Gili From cowwoc at bbs.darktech.org Sat Apr 4 23:27:25 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 01:27:25 -0400 Subject: [Rxtx] Crash in termios.c:892 Message-ID: <49D8413D.7040105@bbs.darktech.org> I can reproduce a crash in RXTX 2.2 pre2 100% of the time using my application code, but I can't seem to bring it down to a minimal testcase. Here is what I see: - thread begins running - open com1 - close com1 - open com5 - leave com5 open - thread shuts down - repeat the same process in a new thread - crash occurs when trying to open com1. Crash disappears if I close() com5 in the previous thread. The output window contains the following: # # A fatal error has been detected by the Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x05475cf6, pid=6064, tid=5436 # # JRE version: 6.0_14-b04 # Java VM: Java HotSpot(TM) Client VM (14.0-b13 mixed mode, sharing windows-x86 ) # Problematic frame: # C [rxtxSerial.dll+0x5cf6] # # An error report file with more information is saved as: # C:\Users\Gili\Documents\foobar\source\hs_err_pid6064.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp Error 0x5 at ..\src\termios.c(892): Access is denied. # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # Please let me know if the crash dump is enough to track down this bug. Thank you, Gili -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: hs_err_pid6064.log Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20090405/7133a1ce/attachment-0009.pl From cowwoc at bbs.darktech.org Sun Apr 5 00:24:19 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 02:24:19 -0400 Subject: [Rxtx] SerialPort.getName() is wrong Message-ID: <49D84E93.7050606@bbs.darktech.org> Sorry for all these emails but I keep on running into more issues. Here is what I noticed: - CommPortIdentifier.getPortIdentifier("COM5") returns a CommPortIdentifier where getName() == "COM5" - If, however, you invoke CommPortIdentifier.open() you get back a SerialPort where SerialPort.getName() is "//./COM5" I am expecting the name to remain consistent. "//./COM5" looks like an implementation detail and (as far as I can tell) it can't be used as an argument for any API method so it is somewhat useless. If getName() were to return "COM5" I could at least use it to get back the original CommPortIdentifier or compare against "known names" such as "COMx" or "LPTx". What do you think? Gili From tjarvi at qbang.org Sun Apr 5 10:18:42 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Apr 2009 10:18:42 -0600 (MDT) Subject: [Rxtx] SerialPort.getName() is wrong In-Reply-To: <49D84E93.7050606@bbs.darktech.org> References: <49D84E93.7050606@bbs.darktech.org> Message-ID: On Sun, 5 Apr 2009, cowwoc wrote: > > Sorry for all these emails but I keep on running into more issues. > Here is what I noticed: > > - CommPortIdentifier.getPortIdentifier("COM5") returns a > CommPortIdentifier where getName() == "COM5" > - If, however, you invoke CommPortIdentifier.open() you get back a > SerialPort where SerialPort.getName() is "//./COM5" > > I am expecting the name to remain consistent. "//./COM5" looks like > an implementation detail and (as far as I can tell) it can't be used as > an argument for any API method so it is somewhat useless. If getName() > were to return "COM5" I could at least use it to get back the original > CommPortIdentifier or compare against "known names" such as "COMx" or > "LPTx". What do you think? > Sure. If it itches enough you should be able to fix this in RXTXCommDriver.java. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Apr 5 10:27:58 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Apr 2009 10:27:58 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D8413D.7040105@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> Message-ID: On Sun, 5 Apr 2009, cowwoc wrote: > > I can reproduce a crash in RXTX 2.2 pre2 100% of the time using my > application code, but I can't seem to bring it down to a minimal testcase. > Here is what I see: > > - thread begins running > - open com1 > - close com1 > - open com5 > - leave com5 open > - thread shuts down > - repeat the same process in a new thread > - crash occurs when trying to open com1. Crash disappears if I close() com5 > in the previous thread. > > The output window contains the following: > > # > # A fatal error has been detected by the Java Runtime Environment: > # > # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x05475cf6, pid=6064, > tid=5436 > # > # JRE version: 6.0_14-b04 > # Java VM: Java HotSpot(TM) Client VM (14.0-b13 mixed mode, sharing > windows-x86 ) > # Problematic frame: > # C [rxtxSerial.dll+0x5cf6] > # > # An error report file with more information is saved as: > # C:\Users\Gili\Documents\foobar\source\hs_err_pid6064.log > # > # If you would like to submit a bug report, please visit: > # http://java.sun.com/webapps/bugreport/crash.jsp > Error 0x5 at ..\src\termios.c(892): Access is denied. > > > # The crash happened outside the Java Virtual Machine in native code. > # See problematic frame for where to report the bug. > # > > Please let me know if the crash dump is enough to track down this bug. > Hi Gili, You are responsible for cleaning up the serial ports when using threads. That said, if the thread did shut down, finalize should have been called if you are not passing the object around. See RXTXPort.java. protected void finalize() { if (debug) z.reportln( "RXTXPort:finalize()"); if( fd > 0 ) { if (debug) z.reportln( "RXTXPort:calling close()"); close(); } z.finalize(); } The exception is interesting. This is on Vista? Usually it just gives an open error when another process has the port. -- Trent Jarvi tjarvi at mathworks.com From cowwoc at bbs.darktech.org Sun Apr 5 10:35:55 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 12:35:55 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: References: <49D8413D.7040105@bbs.darktech.org> Message-ID: <49D8DDEB.5010908@bbs.darktech.org> Trent Jarvi wrote: > You are responsible for cleaning up the serial ports when using threads. > That said, if the thread did shut down, finalize should have been called > if you are not passing the object around. See RXTXPort.java. > > protected void finalize() > { > if (debug) > z.reportln( "RXTXPort:finalize()"); > if( fd > 0 ) > { > if (debug) > z.reportln( "RXTXPort:calling close()"); > close(); > } > z.finalize(); > } Two points: 1) One should never rely on finalizers because they may never run. 2) RXTX shouldn't cause the entire JVM to crash if I misuse the API. The native code should recover more gracefully. > The exception is interesting. This is on Vista? Usually it just gives > an open error when another process has the port. Yes, this is on Vista 64-bit. I'd really like to see this bug fixed. Is this code compilable under Visual Studio? If so, I can debug the problem on my end and send you a patch. Thanks, Gili From cowwoc at bbs.darktech.org Sun Apr 5 10:36:20 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 12:36:20 -0400 Subject: [Rxtx] SerialPort.getName() is wrong In-Reply-To: References: <49D84E93.7050606@bbs.darktech.org> Message-ID: <49D8DE04.6030306@bbs.darktech.org> Trent Jarvi wrote: >> I am expecting the name to remain consistent. "//./COM5" looks like >> an implementation detail and (as far as I can tell) it can't be used as >> an argument for any API method so it is somewhat useless. If getName() >> were to return "COM5" I could at least use it to get back the original >> CommPortIdentifier or compare against "known names" such as "COMx" or >> "LPTx". What do you think? >> > > Sure. > > If it itches enough you should be able to fix this in RXTXCommDriver.java. I'm not sure I understand. Are you saying that if I submit a patch you will commit it? Gili From tjarvi at qbang.org Sun Apr 5 10:46:23 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Apr 2009 10:46:23 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D8DDEB.5010908@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> Message-ID: On Sun, 5 Apr 2009, cowwoc wrote: > Trent Jarvi wrote: >> You are responsible for cleaning up the serial ports when using threads. >> That said, if the thread did shut down, finalize should have been called if >> you are not passing the object around. See RXTXPort.java. >> >> protected void finalize() >> { >> if (debug) >> z.reportln( "RXTXPort:finalize()"); >> if( fd > 0 ) >> { >> if (debug) >> z.reportln( "RXTXPort:calling close()"); >> close(); >> } >> z.finalize(); >> } > > Two points: > > 1) One should never rely on finalizers because they may never run. > 2) RXTX shouldn't cause the entire JVM to crash if I misuse the API. The > native code should recover more gracefully. > >> The exception is interesting. This is on Vista? Usually it just gives an >> open error when another process has the port. > > Yes, this is on Vista 64-bit. I'd really like to see this bug fixed. > Is this code compilable under Visual Studio? If so, I can debug the problem > on my end and send you a patch. > It will compile with the msvc cl.exe and nmake. See Makefile.msvc in the top level directory. You will need to adjust the JAVA_HOME variable. Also use the MSVC command prompt for x86_64 so cl and nmake are on your path. All the best, -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Apr 5 10:49:10 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Apr 2009 10:49:10 -0600 (MDT) Subject: [Rxtx] SerialPort.getName() is wrong In-Reply-To: <49D8DE04.6030306@bbs.darktech.org> References: <49D84E93.7050606@bbs.darktech.org> <49D8DE04.6030306@bbs.darktech.org> Message-ID: On Sun, 5 Apr 2009, cowwoc wrote: > Trent Jarvi wrote: >>> I am expecting the name to remain consistent. "//./COM5" looks like >>> an implementation detail and (as far as I can tell) it can't be used as >>> an argument for any API method so it is somewhat useless. If getName() >>> were to return "COM5" I could at least use it to get back the original >>> CommPortIdentifier or compare against "known names" such as "COMx" or >>> "LPTx". What do you think? >>> >> >> Sure. >> >> If it itches enough you should be able to fix this in RXTXCommDriver.java. > > I'm not sure I understand. Are you saying that if I submit a patch > you will commit it? > Hi Gili, Post a patch here and if nobody complains, we will commit it and give you credit. Yep. Other issues like changing the API to use java5 that may break existing apps are likely to run into objections but bug fixes usually get fixed just as you mention. -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Sun Apr 5 10:55:07 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 12:55:07 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> Message-ID: <49D8E26B.2040705@bbs.darktech.org> Trent Jarvi wrote: > It will compile with the msvc cl.exe and nmake. See Makefile.msvc in > the top level directory. You will need to adjust the JAVA_HOME > variable. Also use the MSVC command prompt for x86_64 so cl and nmake > are on your path. This is very odd. The CVS version of the code does not contain this file. Do you keep the latest code somewhere else? Gili From cowwoc at bbs.darktech.org Sun Apr 5 11:01:58 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 13:01:58 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D8E26B.2040705@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> Message-ID: <49D8E406.10708@bbs.darktech.org> cowwoc wrote: > Trent Jarvi wrote: >> It will compile with the msvc cl.exe and nmake. See Makefile.msvc in >> the top level directory. You will need to adjust the JAVA_HOME >> variable. Also use the MSVC command prompt for x86_64 so cl and nmake >> are on your path. > > This is very odd. The CVS version of the code does not contain this > file. Do you keep the latest code somewhere else? Okay I figured it out. CVS head is out of date, the "commapi-0-0-1" revision contains the correct files. Gili From tjarvi at qbang.org Sun Apr 5 11:05:43 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Apr 2009 11:05:43 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D8E26B.2040705@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> Message-ID: CVS HEAD is currently the rxtx 2.0 code. A branch was created long ago for 'experimental' gnu.io work. It just happens that the branch is what everyone uses now. checkout -r commapi-0-0-1 rxtx-devel will get the branch On Sun, 5 Apr 2009, cowwoc wrote: > Trent Jarvi wrote: >> It will compile with the msvc cl.exe and nmake. See Makefile.msvc in the >> top level directory. You will need to adjust the JAVA_HOME variable. Also >> use the MSVC command prompt for x86_64 so cl and nmake are on your path. > > This is very odd. The CVS version of the code does not contain this > file. Do you keep the latest code somewhere else? > > Gili > From cowwoc at bbs.darktech.org Sun Apr 5 14:50:47 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 16:50:47 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> Message-ID: <49D919A7.1070806@bbs.darktech.org> Okay, I tracked down the crash. It's being caused by YACK() using a 80-character buffer. The error message is longer than 80 characters, so _snprintf_s() crashes to avoid a buffer overflow. Please apply the attached patch and add the zipped up Visual Studio project directory. It's not perfect yet but it's a good start. Gili Trent Jarvi wrote: > > CVS HEAD is currently the rxtx 2.0 code. A branch was created long > ago for 'experimental' gnu.io work. It just happens that the branch > is what everyone uses now. > > checkout -r commapi-0-0-1 rxtx-devel > > will get the branch > > On Sun, 5 Apr 2009, cowwoc wrote: > >> Trent Jarvi wrote: >>> It will compile with the msvc cl.exe and nmake. See Makefile.msvc >>> in the top level directory. You will need to adjust the JAVA_HOME >>> variable. Also use the MSVC command prompt for x86_64 so cl and >>> nmake are on your path. >> >> This is very odd. The CVS version of the code does not contain >> this file. Do you keep the latest code somewhere else? >> >> Gili >> -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx-devel.patch Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20090405/d9b82962/attachment-0008.pl -------------- next part -------------- A non-text attachment was scrubbed... Name: Win32.zip Type: application/octet-stream Size: 17764 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20090405/d9b82962/attachment-0010.obj From cowwoc at bbs.darktech.org Sun Apr 5 15:22:01 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 17:22:01 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D919A7.1070806@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> <49D919A7.1070806@bbs.darktech.org> Message-ID: <49D920F9.6080702@bbs.darktech.org> My mistake. The problem in YACK is real, but it isn't the real cause of the crash. The crash is caused by termios.c line 1099: index->prev->next = port; because in my case "index->prev==0". I think the bug is that the code assumes that index will contain a minimum of two entries if we're inserting a previously closed fd. In my case, it only contains one. I'm not sure why you have this code branch (as opposed to appending to the end of index). Please take a look. Thanks, Gili cowwoc wrote: > > Okay, I tracked down the crash. It's being caused by YACK() using a > 80-character buffer. The error message is longer than 80 characters, so > _snprintf_s() crashes to avoid a buffer overflow. > > Please apply the attached patch and add the zipped up Visual Studio > project directory. It's not perfect yet but it's a good start. > > Gili > > Trent Jarvi wrote: >> >> CVS HEAD is currently the rxtx 2.0 code. A branch was created long >> ago for 'experimental' gnu.io work. It just happens that the branch >> is what everyone uses now. >> >> checkout -r commapi-0-0-1 rxtx-devel >> >> will get the branch >> >> On Sun, 5 Apr 2009, cowwoc wrote: >> >>> Trent Jarvi wrote: >>>> It will compile with the msvc cl.exe and nmake. See Makefile.msvc >>>> in the top level directory. You will need to adjust the JAVA_HOME >>>> variable. Also use the MSVC command prompt for x86_64 so cl and >>>> nmake are on your path. >>> >>> This is very odd. The CVS version of the code does not contain >>> this file. Do you keep the latest code somewhere else? >>> >>> Gili >>> From tjarvi at qbang.org Sun Apr 5 16:13:27 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Apr 2009 16:13:27 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D920F9.6080702@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> <49D919A7.1070806@bbs.darktech.org> <49D920F9.6080702@bbs.darktech.org> Message-ID: Hi Gili, Are you using the cvs version? I thought we fixed the linked list issues. A solution was posted to the list. Let me look at work tomorrow to see what I have. On Sun, 5 Apr 2009, cowwoc wrote: > > My mistake. The problem in YACK is real, but it isn't the real cause > of the crash. The crash is caused by termios.c line 1099: > > index->prev->next = port; > > because in my case "index->prev==0". I think the bug is that the code > assumes that index will contain a minimum of two entries if we're inserting a > previously closed fd. In my case, it only contains one. > > I'm not sure why you have this code branch (as opposed to appending > to the end of index). Please take a look. > > Thanks, > Gili > > cowwoc wrote: >> >> Okay, I tracked down the crash. It's being caused by YACK() using a >> 80-character buffer. The error message is longer than 80 characters, so >> _snprintf_s() crashes to avoid a buffer overflow. >> >> Please apply the attached patch and add the zipped up Visual Studio >> project directory. It's not perfect yet but it's a good start. >> >> Gili >> >> Trent Jarvi wrote: >>> >>> CVS HEAD is currently the rxtx 2.0 code. A branch was created long ago >>> for 'experimental' gnu.io work. It just happens that the branch is what >>> everyone uses now. >>> >>> checkout -r commapi-0-0-1 rxtx-devel >>> >>> will get the branch >>> >>> On Sun, 5 Apr 2009, cowwoc wrote: >>> >>>> Trent Jarvi wrote: >>>>> It will compile with the msvc cl.exe and nmake. See Makefile.msvc in >>>>> the top level directory. You will need to adjust the JAVA_HOME >>>>> variable. Also use the MSVC command prompt for x86_64 so cl and nmake >>>>> are on your path. >>>> >>>> This is very odd. The CVS version of the code does not contain this >>>> file. Do you keep the latest code somewhere else? >>>> >>>> Gili >>>> > From ilkka at myller.com Sun Apr 5 23:58:08 2009 From: ilkka at myller.com (Ilkka Myller) Date: Mon, 6 Apr 2009 08:58:08 +0300 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> <49D919A7.1070806@bbs.darktech.org> <49D920F9.6080702@bbs.darktech.org> Message-ID: <19779C97-E0C7-4E3D-B715-F84F50F00CE6@myller.com> Hi all, I've already submitted the patch to fix this issue in february: http://mailman.qbang.org/pipermail/rxtx/2009-February/3989441.html The patch fixes the mentioned doubly linked list handling in termios.c -- I Trent Jarvi kirjoitti 6.4.2009 kello 1.13: > > Hi Gili, > > Are you using the cvs version? I thought we fixed the linked list > issues. > A solution was posted to the list. Let me look at work tomorrow to > see > what I have. > > > > On Sun, 5 Apr 2009, cowwoc wrote: > >> >> My mistake. The problem in YACK is real, but it isn't the real cause >> of the crash. The crash is caused by termios.c line 1099: >> >> index->prev->next = port; >> >> because in my case "index->prev==0". I think the bug is that the >> code >> assumes that index will contain a minimum of two entries if we're >> inserting a >> previously closed fd. In my case, it only contains one. >> >> I'm not sure why you have this code branch (as opposed to appending >> to the end of index). Please take a look. >> >> Thanks, >> Gili >> >> cowwoc wrote: >>> >>> Okay, I tracked down the crash. It's being caused by YACK() >>> using a >>> 80-character buffer. The error message is longer than 80 >>> characters, so >>> _snprintf_s() crashes to avoid a buffer overflow. >>> >>> Please apply the attached patch and add the zipped up Visual >>> Studio >>> project directory. It's not perfect yet but it's a good start. >>> >>> Gili >>> >>> Trent Jarvi wrote: >>>> >>>> CVS HEAD is currently the rxtx 2.0 code. A branch was created >>>> long ago >>>> for 'experimental' gnu.io work. It just happens that the branch >>>> is what >>>> everyone uses now. >>>> >>>> checkout -r commapi-0-0-1 rxtx-devel >>>> >>>> will get the branch >>>> >>>> On Sun, 5 Apr 2009, cowwoc wrote: >>>> >>>>> Trent Jarvi wrote: >>>>>> It will compile with the msvc cl.exe and nmake. See >>>>>> Makefile.msvc in >>>>>> the top level directory. You will need to adjust the JAVA_HOME >>>>>> variable. Also use the MSVC command prompt for x86_64 so cl and >>>>>> nmake >>>>>> are on your path. >>>>> >>>>> This is very odd. The CVS version of the code does not >>>>> contain this >>>>> file. Do you keep the latest code somewhere else? >>>>> >>>>> Gili >>>>> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Steffen.DETTMER at ingenico.com Mon Apr 6 02:53:47 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 6 Apr 2009 10:53:47 +0200 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D919A7.1070806@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> <49D919A7.1070806@bbs.darktech.org> Message-ID: <20090406085347.GM8289@elberon.bln.de.ingenico.com> Hi, just two minor details, first about the errno change, I though #include extern int errno; is correct (POSIX.1) - why this change? second about the log message, I think the maximum length could be limited and the return value of malloc must be checked for != NULL before using. Should it be _snprintf_s( message, 80, _TRUNCATE, "Error 0x%x at %s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); (I know that MS-CRT _snprintf does not guarantee to have a final EOS, but I think _snprintf_s with _TRUNCATE does so?). If it is known that truncation may happen maybe sizeof[message] could be increased; maybe using some %.20s could be used avoiding __FILE__ including big pathes to a message where all the message had been cut-off. To have it portable I think it could be: /* generally: */ #if defined(_MSC_VER) # define snprintf _snprintf #endif snprintf(message, sizeof(message), "Error 0x%x at %.20s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); message[sizeof(message)-1] = '\0'; /* needed for MS CRT snprintf */ (for length and size parameter I think size_t could be an option, but on several platforms, including MS-CRT and older glibc, there is no %z, unfortunately) oki, Steffen * cowwoc wrote on Sun, Apr 05, 2009 at 16:50 -0400: > > Okay, I tracked down the crash. It's being caused by YACK() using a > 80-character buffer. The error message is longer than 80 characters, so > _snprintf_s() crashes to avoid a buffer overflow. > > Please apply the attached patch and add the zipped up Visual Studio > project directory. It's not perfect yet but it's a good start. > > Gili > > Trent Jarvi wrote: > > > >CVS HEAD is currently the rxtx 2.0 code. A branch was created long > >ago for 'experimental' gnu.io work. It just happens that the branch > >is what everyone uses now. > > > >checkout -r commapi-0-0-1 rxtx-devel > > > >will get the branch > > > >On Sun, 5 Apr 2009, cowwoc wrote: > > > >>Trent Jarvi wrote: > >>>It will compile with the msvc cl.exe and nmake. See Makefile.msvc > >>>in the top level directory. You will need to adjust the JAVA_HOME > >>>variable. Also use the MSVC command prompt for x86_64 so cl and > >>>nmake are on your path. > >> > >> This is very odd. The CVS version of the code does not contain > >>this file. Do you keep the latest code somewhere else? > >> > >>Gili > >> > Index: ParallelImp.c > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/ParallelImp.c,v > retrieving revision 1.15.2.36 > diff -u -r1.15.2.36 ParallelImp.c > --- ParallelImp.c 11 Feb 2009 01:04:19 -0000 1.15.2.36 > +++ ParallelImp.c 5 Apr 2009 17:55:23 -0000 > @@ -119,7 +119,7 @@ > # include > #endif > > -extern int errno; > +_CRTIMP extern int * __cdecl _errno(void); > > #include "ParallelImp.h" > > @@ -181,8 +181,6 @@ > > #if defined (WIN32) > > -#define CTL_CODE( DeviceType, Function, Method, Access ) (((DeviceType) << 16) | ((Access) << 14) | ((Function) << 2) | (Method)) > - > #define FILE_DEVICE_PARALLEL_PORT 0x00000016 > #define METHOD_BUFFERED 0 > #define FILE_ANY_ACCESS 0 > @@ -253,7 +251,6 @@ > jobject jobj) > { > int fd = get_java_var( env, jobj,"fd","I" ); > - int status; > #if defined (__linux__) > ioctl(fd, LPGETSTATUS, &status); > #elif defined (WIN32) > Index: SerialImp.c > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v > retrieving revision 1.46.2.203 > diff -u -r1.46.2.203 SerialImp.c > --- SerialImp.c 19 Mar 2009 03:27:48 -0000 1.46.2.203 > +++ SerialImp.c 5 Apr 2009 17:49:48 -0000 > @@ -147,7 +147,7 @@ > #include > #endif /* LIBLOCKDEV */ > > -extern int errno; > +_CRTIMP extern int * __cdecl _errno(void); > > #include "SerialImp.h" > > Index: termios.c > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/termios.c,v > retrieving revision 1.9.2.62 > diff -u -r1.9.2.62 termios.c > --- termios.c 13 Jan 2009 03:08:55 -0000 1.9.2.62 > +++ termios.c 5 Apr 2009 17:54:09 -0000 > @@ -88,7 +88,7 @@ > #define SIGIO 0 > > int my_errno; > -extern int errno; > +_CRTIMP extern int * __cdecl _errno(void); > struct termios_list > { > char filename[80]; > @@ -1350,7 +1350,7 @@ > In that case use EAGAIN. See SerialImp.c:testRead() > ----------------------------------------------------------*/ > > -int serial_read( int fd, void *vb, int size ) > +int serial_read( int fd, void *vb, unsigned int size ) > { > long start, now; > unsigned long nBytes = 0, total = 0, error; > Index: win32termios.h > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/win32termios.h,v > retrieving revision 1.5.2.34 > diff -u -r1.5.2.34 win32termios.h > --- win32termios.h 5 Feb 2009 01:25:05 -0000 1.5.2.34 > +++ win32termios.h 5 Apr 2009 20:29:30 -0000 > @@ -60,6 +60,7 @@ > #include > #include > #include > +#include > #ifdef TRACE > #define ENTER(x) report("entering "x" \n"); > #define LEAVE(x) report("leaving "x" \n"); > @@ -70,8 +71,9 @@ > #if defined(_MSC_VER) > #define YACK() \ > { \ > - char *allocTextBuf, message[80]; \ > - unsigned long nChars; \ > + char *allocTextBuf, *message; \ > + const unsigned short longestNumber = 20; \ > + unsigned long nChars, len; \ > unsigned int errorCode = GetLastError(); \ > nChars = FormatMessage ( \ > FORMAT_MESSAGE_ALLOCATE_BUFFER | \ > @@ -82,8 +84,12 @@ > (LPSTR)&allocTextBuf, \ > 16, \ > NULL ); \ > - _snprintf_s( message, 80, 80, "Error 0x%x at %s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); \ > + len = strlen("Error 0x") + longestNumber + strlen(" at ") + strlen(__FILE__) + longestNumber + \ > + strlen(": ") + ((nChars+1) * sizeof(TCHAR)) + 1; \ > + message = malloc(len); \ > + _snprintf_s( message, len, len - 1, "Error 0x%x at %s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); \ > report_error( message ); \ > + free(message); \ > LocalFree(allocTextBuf); \ > Sleep(1); \ > } > @@ -173,7 +179,7 @@ > int serial_test( char * ); > int serial_open(const char *File, int flags, ... ); > int serial_close(int fd); > -int serial_read(int fd, void *b, int size); > +int serial_read(int fd, void *b, unsigned int size); > int serial_write(int fd, char *Str, int length); > /* > * lcc winsock.h conflicts > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx End of message. ------------------------------------------------------------------->8======= About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From bill7007 at gmail.com Mon Apr 6 16:34:50 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Mon, 6 Apr 2009 18:34:50 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: <49D693BA.8060909@gatworks.com> References: <49D546F8.20807@gatworks.com> <49D693BA.8060909@gatworks.com> Message-ID: Once it hung, three stack dumps minutes apart were exactly the same. I have a noticed that when it hangs, the read appears after flush() enter and before flush leave() that doesn't happen like: RXTXPort:SerialOutputStream:flush() enter RXTXPort:SerialInputStream:read(8192 0 8192) called When it works, flush() enter and leave happen together. It may just be because flush() hangs and read is the only other thread waiting to run at that point. I don't know much about the RXTX design and kernel interaction, just digging through the code some. Is there a design description somewhere? Am hung up on target system compile since UTS_RELEASE seems no longer defined for 2.6.18 up kernels and have not figured a good patch yet. But, that is another issue. Thanks for the good help. On Fri, Apr 3, 2009 at 6:54 PM, U. George wrote: > I would have tried 2 or 3 "^\" . If things are stuck, then all will be at > same 'java' instruction. If thread is moving, then one of the snapshots > would be different. > > I *think* flushing/draining wont return until the kernel buffers to device > have been accepted by device. Stuck/paused device? > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090406/c4b509d8/attachment-0009.html From tjarvi at qbang.org Mon Apr 6 17:45:38 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 6 Apr 2009 17:45:38 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <20090406085347.GM8289@elberon.bln.de.ingenico.com> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> <49D919A7.1070806@bbs.darktech.org> <20090406085347.GM8289@elberon.bln.de.ingenico.com> Message-ID: The error bits in the patch can probably just be dropped out. I don't see what they solve. Your snprintf define appears to work. The following is what I'd like to put in if noone objects. #if defined(_MSC_VER) # define snprintf _snprintf #endif #define YACK() \ { \ char *allocTextBuf, message[80]; \ unsigned long nChars; \ unsigned int errorCode = GetLastError(); \ nChars = FormatMessage ( \ FORMAT_MESSAGE_ALLOCATE_BUFFER | \ FORMAT_MESSAGE_FROM_SYSTEM, \ NULL, \ errorCode, \ MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT), \ (LPSTR)&allocTextBuf, \ 16, \ NULL ); \ snprintf( message, 80, "Error 0x%x at %s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); \ message[sizeof(message)-1] = '\0'; /* needed for MS CRT snprintf */ \ report_error( message ); \ LocalFree(allocTextBuf); \ Sleep(1); \ } On Mon, 6 Apr 2009, Steffen DETTMER wrote: > Hi, > > just two minor details, first about the errno change, I though > > #include > extern int errno; > > is correct (POSIX.1) - why this change? > > second about the log message, I think the maximum length could be > limited and the return value of malloc must be checked for != > NULL before using. > > Should it be > > _snprintf_s( message, 80, _TRUNCATE, "Error 0x%x at %s(%d): %s\n", > errorCode, __FILE__, __LINE__, allocTextBuf); > > (I know that MS-CRT _snprintf does not guarantee to have a final > EOS, but I think _snprintf_s with _TRUNCATE does so?). > > If it is known that truncation may happen maybe sizeof[message] > could be increased; maybe using some %.20s could be used avoiding > __FILE__ including big pathes to a message where all the message > had been cut-off. > > To have it portable I think it could be: > > /* generally: */ > #if defined(_MSC_VER) > # define snprintf _snprintf > #endif > > snprintf(message, sizeof(message), "Error 0x%x at %.20s(%d): %s\n", > errorCode, __FILE__, __LINE__, allocTextBuf); > message[sizeof(message)-1] = '\0'; /* needed for MS CRT snprintf */ > > (for length and size parameter I think size_t could be an option, > but on several platforms, including MS-CRT and older glibc, > there is no %z, unfortunately) > > oki, > > Steffen > > > * cowwoc wrote on Sun, Apr 05, 2009 at 16:50 -0400: >> >> Okay, I tracked down the crash. It's being caused by YACK() using a >> 80-character buffer. The error message is longer than 80 characters, so >> _snprintf_s() crashes to avoid a buffer overflow. >> >> Please apply the attached patch and add the zipped up Visual Studio >> project directory. It's not perfect yet but it's a good start. >> >> Gili >> >> Trent Jarvi wrote: >> > >> >CVS HEAD is currently the rxtx 2.0 code. A branch was created long >> >ago for 'experimental' gnu.io work. It just happens that the branch >> >is what everyone uses now. >> > >> >checkout -r commapi-0-0-1 rxtx-devel >> > >> >will get the branch >> > >> >On Sun, 5 Apr 2009, cowwoc wrote: >> > >> >>Trent Jarvi wrote: >> >>>It will compile with the msvc cl.exe and nmake. See Makefile.msvc >> >>>in the top level directory. You will need to adjust the JAVA_HOME >> >>>variable. Also use the MSVC command prompt for x86_64 so cl and >> >>>nmake are on your path. >> >> >> >> This is very odd. The CVS version of the code does not contain >> >>this file. Do you keep the latest code somewhere else? >> >> >> >>Gili >> >> > >> Index: ParallelImp.c >> =================================================================== >> RCS file: /usr/local/cvsroot/rxtx-devel/src/ParallelImp.c,v >> retrieving revision 1.15.2.36 >> diff -u -r1.15.2.36 ParallelImp.c >> --- ParallelImp.c 11 Feb 2009 01:04:19 -0000 1.15.2.36 >> +++ ParallelImp.c 5 Apr 2009 17:55:23 -0000 >> @@ -119,7 +119,7 @@ >> # include >> #endif >> >> -extern int errno; >> +_CRTIMP extern int * __cdecl _errno(void); >> >> #include "ParallelImp.h" >> >> @@ -181,8 +181,6 @@ >> >> #if defined (WIN32) >> >> -#define CTL_CODE( DeviceType, Function, Method, Access ) (((DeviceType) << 16) | ((Access) << 14) | ((Function) << 2) | (Method)) >> - >> #define FILE_DEVICE_PARALLEL_PORT 0x00000016 >> #define METHOD_BUFFERED 0 >> #define FILE_ANY_ACCESS 0 >> @@ -253,7 +251,6 @@ >> jobject jobj) >> { >> int fd = get_java_var( env, jobj,"fd","I" ); >> - int status; >> #if defined (__linux__) >> ioctl(fd, LPGETSTATUS, &status); >> #elif defined (WIN32) >> Index: SerialImp.c >> =================================================================== >> RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v >> retrieving revision 1.46.2.203 >> diff -u -r1.46.2.203 SerialImp.c >> --- SerialImp.c 19 Mar 2009 03:27:48 -0000 1.46.2.203 >> +++ SerialImp.c 5 Apr 2009 17:49:48 -0000 >> @@ -147,7 +147,7 @@ >> #include >> #endif /* LIBLOCKDEV */ >> >> -extern int errno; >> +_CRTIMP extern int * __cdecl _errno(void); >> >> #include "SerialImp.h" >> >> Index: termios.c >> =================================================================== >> RCS file: /usr/local/cvsroot/rxtx-devel/src/termios.c,v >> retrieving revision 1.9.2.62 >> diff -u -r1.9.2.62 termios.c >> --- termios.c 13 Jan 2009 03:08:55 -0000 1.9.2.62 >> +++ termios.c 5 Apr 2009 17:54:09 -0000 >> @@ -88,7 +88,7 @@ >> #define SIGIO 0 >> >> int my_errno; >> -extern int errno; >> +_CRTIMP extern int * __cdecl _errno(void); >> struct termios_list >> { >> char filename[80]; >> @@ -1350,7 +1350,7 @@ >> In that case use EAGAIN. See SerialImp.c:testRead() >> ----------------------------------------------------------*/ >> >> -int serial_read( int fd, void *vb, int size ) >> +int serial_read( int fd, void *vb, unsigned int size ) >> { >> long start, now; >> unsigned long nBytes = 0, total = 0, error; >> Index: win32termios.h >> =================================================================== >> RCS file: /usr/local/cvsroot/rxtx-devel/src/win32termios.h,v >> retrieving revision 1.5.2.34 >> diff -u -r1.5.2.34 win32termios.h >> --- win32termios.h 5 Feb 2009 01:25:05 -0000 1.5.2.34 >> +++ win32termios.h 5 Apr 2009 20:29:30 -0000 >> @@ -60,6 +60,7 @@ >> #include >> #include >> #include >> +#include >> #ifdef TRACE >> #define ENTER(x) report("entering "x" \n"); >> #define LEAVE(x) report("leaving "x" \n"); >> @@ -70,8 +71,9 @@ >> #if defined(_MSC_VER) >> #define YACK() \ >> { \ >> - char *allocTextBuf, message[80]; \ >> - unsigned long nChars; \ >> + char *allocTextBuf, *message; \ >> + const unsigned short longestNumber = 20; \ >> + unsigned long nChars, len; \ >> unsigned int errorCode = GetLastError(); \ >> nChars = FormatMessage ( \ >> FORMAT_MESSAGE_ALLOCATE_BUFFER | \ >> @@ -82,8 +84,12 @@ >> (LPSTR)&allocTextBuf, \ >> 16, \ >> NULL ); \ >> - _snprintf_s( message, 80, 80, "Error 0x%x at %s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); \ >> + len = strlen("Error 0x") + longestNumber + strlen(" at ") + strlen(__FILE__) + longestNumber + \ >> + strlen(": ") + ((nChars+1) * sizeof(TCHAR)) + 1; \ >> + message = malloc(len); \ >> + _snprintf_s( message, len, len - 1, "Error 0x%x at %s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); \ >> report_error( message ); \ >> + free(message); \ >> LocalFree(allocTextBuf); \ >> Sleep(1); \ >> } >> @@ -173,7 +179,7 @@ >> int serial_test( char * ); >> int serial_open(const char *File, int flags, ... ); >> int serial_close(int fd); >> -int serial_read(int fd, void *b, int size); >> +int serial_read(int fd, void *b, unsigned int size); >> int serial_write(int fd, char *Str, int length); >> /* >> * lcc winsock.h conflicts >> > > >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > > > > > > > > > > > > End of message. > ------------------------------------------------------------------->8======= > > > About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. > This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > P Please consider the environment before printing this e-mail > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Apr 6 18:11:28 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 6 Apr 2009 18:11:28 -0600 (MDT) Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: <49D546F8.20807@gatworks.com> <49D693BA.8060909@gatworks.com> Message-ID: UTS_RELEASE is defined in now. The check really should be removed from RXTX. It was a defensive check for wilder times when GNU glibc did not have defines the kernel headers had so rxtx would include the kernel headers instead. :/ If you don't have linux/version.h, it is generated when you configure the kernel. make oldconfig used to do the trick. It may make sense to work with the prerelease or CVS code. RXTX just assumes that flush, read and anything else the kernel exposes may be called at anytime from any thread. There isn't a design for the kernel interaction. There are higher level constraints put in Java to prevent some things happening at the same time with 'synchronized.' RXTXPort.java has all of those. When the port is opened, a native event thread is started which uses select to know if an event has happened. BSD like systems have a native thread that fires off on write which tries to flush() to determine when the output buffer is empty asynchronously. The rest is not marshaled in any fashion at the native level. T I think there is a lower level deadlock being triggered in flush as well. I don't think it should be possible if everything was right underneath us. You may want to examine the java code closer to make sure it isnt possible the lock is there. On Mon, 6 Apr 2009, Bill Johnson wrote: > Once it hung, three stack dumps minutes apart were exactly the same. > I have a noticed that when it hangs, the read appears after flush() enter and > before flush leave() that doesn't happen like: > RXTXPort:SerialOutputStream:flush() enter > RXTXPort:SerialInputStream:read(8192 0 8192) called > > When it works, flush() enter and leave happen together. It may just be because > flush() hangs and read is the only other thread waiting to run at that point. > I don't know much about the RXTX design and kernel interaction, just digging > through the code some. Is there a design description somewhere? > > Am hung up on target system compile since UTS_RELEASE seems no longer defined for > 2.6.18 up kernels and have not figured a good patch yet. But, that is another > issue. > > Thanks for the good help. > > > On Fri, Apr 3, 2009 at 6:54 PM, U. George wrote: > I would have tried 2 or 3 "^\" . If things are stuck, then all will be > at same 'java' instruction. If thread is moving, then one of the > snapshots would be different. > > I *think* flushing/draining wont return until the kernel buffers to > device have been accepted by device. Stuck/paused device? > > > > > From tjarvi at qbang.org Mon Apr 6 18:28:50 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 6 Apr 2009 18:28:50 -0600 (MDT) Subject: [Rxtx] CVS updates. Pre3 is comming. Message-ID: I need to go through the bugzilla reports prior to the pre3 release. I think this should be close if you want to check it out from CVS. added: YACK() debug overflow fix for windows Steffen DETTMER (and many others) multiport fix for windows. Ilkka Myller http://mailman.qbang.org/pipermail/rxtx/2009-February/3989441.html I think this code is current. If I missed something, yell. CVS Info: export/setenv CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login # passwd mousy cvs checkout -r commapi-0-0-1 rxtx-devel -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Apr 6 22:32:07 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 6 Apr 2009 22:32:07 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D919A7.1070806@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> <49D919A7.1070806@bbs.darktech.org> Message-ID: Ah. I'll put this in CVS tomorrow. I did sync up the code with my work sandbox today. I just forgot to pull and add this. On Sun, 5 Apr 2009, cowwoc wrote: > > Okay, I tracked down the crash. It's being caused by YACK() using a > 80-character buffer. The error message is longer than 80 characters, so > _snprintf_s() crashes to avoid a buffer overflow. > > Please apply the attached patch and add the zipped up Visual Studio > project directory. It's not perfect yet but it's a good start. > > Gili > > Trent Jarvi wrote: >> >> CVS HEAD is currently the rxtx 2.0 code. A branch was created long ago for >> 'experimental' gnu.io work. It just happens that the branch is what >> everyone uses now. >> >> checkout -r commapi-0-0-1 rxtx-devel >> >> will get the branch >> >> On Sun, 5 Apr 2009, cowwoc wrote: >> >>> Trent Jarvi wrote: >>>> It will compile with the msvc cl.exe and nmake. See Makefile.msvc in the >>>> top level directory. You will need to adjust the JAVA_HOME variable. >>>> Also use the MSVC command prompt for x86_64 so cl and nmake are on your >>>> path. >>> >>> This is very odd. The CVS version of the code does not contain this >>> file. Do you keep the latest code somewhere else? >>> >>> Gili >>> > From cowwoc at bbs.darktech.org Tue Apr 7 06:07:46 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Tue, 07 Apr 2009 08:07:46 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: References: Message-ID: <49DB4212.40807@bbs.darktech.org> > just two minor details, first about the errno change, I though > > #include > extern int errno; > > is correct (POSIX.1) - why this change? If you compile this under Visual Studio 2008 you will get warnings that the errno type being imported is different from the type being exported. The definition I pasted is the one being exported. Perhaps we should use #ifdef WIN32 for this? Gili From bill7007 at gmail.com Tue Apr 7 17:58:54 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Tue, 7 Apr 2009 19:58:54 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: <49D546F8.20807@gatworks.com> <49D693BA.8060909@gatworks.com> Message-ID: I have traced the hang down to a call to tcdrain(fd) in SerialImp.c:drain() running and rebuilt under Netbeans on the target machine with debug messages on. That puts it into the system code, so I'm not sure how to proceed. I guess I could debug into the kernel source but I've not done that. I saw some discussion about an IOCTL that sets/adjusts a timeout on tcdrain() but that may have been for BSD. Maybe there is some new setup requirement or bug introduced with this 2.6.18 kernel or a hardware difference. Below is a message listing with some of the repeated parts removed. Maybe you can see something noteworthy? JNI_OnLoad called. WARNING: RXTX Version mismatch Jar version = RXTX-2.2pre2 native lib Version = RXTX-2.2pre3 entering RXTXCommDriver:getDeviceDirectory entering RXTXPort:testRead fhs_lock: creating lockfile: 29704 fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXPort:testRead RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB2 fhs_lock: creating lockfile: 29704 fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXPort:testRead RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB1 fhs_lock: creating lockfile: 29704 fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXPort:testRead RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB0 fhs_lock: creating lockfile: 29704 fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXPort:testRead fhs_lock: creating lockfile: 29704 ... REPEATS fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXPort:testRead fhs_lock: creating lockfile: 29704 fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXCommDriver:getDeviceDirectory entering RXTXPort:testRead fhs_lock: creating lockfile: 29704 ...REPEATS fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXPort:testRead fhs_lock: creating lockfile: 29704 fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXPort:Initialize RXTX WARNING: This library was compiled to run with OS release 2.6.18 and you are currently running OS release 2.6.18-92.1.6.el5. In some cases this can be a problem. Try recompiling RXTX if you notice strange behavior. If you just compiled RXTX make sure /usr/include/linux is a symbolic link to the include files that came with the kernel source and not an older copy. press enter to continue leaving RXTXPort:Initialize entering RXTXPort:open fhs_lock: creating lockfile: 29704 open: locking worked for /dev/ttyUSB2 open: fd returned is 9 leaving RXTXPort:open entering eventLoop has_line_status_register_acess: Port does not support TIOCSERGETLSR driver_has_tiocgicount: Port does not support TIOCGICOUNT events init_threads: get eis init_threads: set eis init_threads: stop leaving RXTXPort:translate_speed entering RXTXPort:nativeSetSerialPortParams entering translate_date_bits entering translate_stop_bits leaving RXTXPort:translate_stop_bits entering translate_parity leaving translate_parity entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 ...REPEATS entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 leaving RXTXPort:nativeSetSerialPortParams entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 ...REPEATS entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 entering writeArray entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 writeArray() leaving RXTXPort:writeArray entering SerialImp.c:drain() nativeDrain: trying tcdrain RXTXPort:drain() returns: 0 leaving RXTXPort:drain() entering writeArray writeArray() leaving RXTXPort:writeArray entering SerialImp.c:drain() nativeDrain: trying tcdrain entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 Tue Apr 07 18:51:49 EDT 2009:TSerial[22]:Using Port:/dev/ttyUSB2 Tue Apr 07 18:51:49 EDT 2009:TSerial[22].Transmit:TN Tue Apr 07 18:51:49 EDT 2009:TSerial[22].Transmit:RV entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 ...REPEATS FOREVER? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090407/f26e5752/attachment-0008.html From tjarvi at qbang.org Tue Apr 7 18:31:23 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 7 Apr 2009 18:31:23 -0600 (MDT) Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: <49D546F8.20807@gatworks.com> <49D693BA.8060909@gatworks.com> Message-ID: On Tue, 7 Apr 2009, Bill Johnson wrote: > I have traced the hang down to a call to tcdrain(fd) in SerialImp.c:drain() > running and rebuilt under Netbeans on the target machine with debug messages > on. That puts it into the system code, so I'm not sure how to proceed. I > guess I could debug into the kernel source but I've not done that. I saw > some discussion about an IOCTL that sets/adjusts a timeout on tcdrain() but > that may have been for BSD. Maybe there is some new setup requirement or bug > introduced with this 2.6.18 kernel or a hardware difference. > Below is a message listing with some of the repeated parts removed. Maybe > you can see something noteworthy? > > JNI_OnLoad called. > WARNING:? RXTX Version mismatch > ??????? Jar version = RXTX-2.2pre2 > ??????? native lib Version = RXTX-2.2pre3 > entering RXTXCommDriver:getDeviceDirectory > entering RXTXPort:testRead > fhs_lock: creating lockfile:????? 29704 > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXPort:testRead > RXTX Warning:? Removing stale lock file. /var/lock/LCK..ttyUSB2 > fhs_lock: creating lockfile:????? 29704 > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXPort:testRead > RXTX Warning:? Removing stale lock file. /var/lock/LCK..ttyUSB1 > fhs_lock: creating lockfile:????? 29704 > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXPort:testRead > RXTX Warning:? Removing stale lock file. /var/lock/LCK..ttyUSB0 > fhs_lock: creating lockfile:????? 29704 > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXPort:testRead > fhs_lock: creating lockfile:????? 29704 > > ... REPEATS > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXPort:testRead > fhs_lock: creating lockfile:????? 29704 > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXCommDriver:getDeviceDirectory > entering RXTXPort:testRead > fhs_lock: creating lockfile:????? 29704 > > ...REPEATS > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXPort:testRead > fhs_lock: creating lockfile:????? 29704 > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXPort:Initialize > > > > RXTX WARNING:? This library was compiled to run with OS release 2.6.18 and > you are currently running OS release 2.6.18-92.1.6.el5.? In some cases this > can be a problem.? Try recompiling RXTX if you notice strange behavior.? If > you just compiled RXTX make sure /usr/include/linux is a symbolic link to > the include files that came with the kernel source and not an older copy. > > > press enter to continue > > leaving RXTXPort:Initialize > entering RXTXPort:open > fhs_lock: creating lockfile:????? 29704 > > open: locking worked for /dev/ttyUSB2 > open: fd returned is 9 > leaving RXTXPort:open > entering eventLoop > ? > has_line_status_register_acess: Port does not support TIOCSERGETLSR > ?driver_has_tiocgicount:? Port does not support TIOCGICOUNT events > init_threads: get eis > init_threads: set eis > init_threads:? stop > leaving RXTXPort:translate_speed > entering RXTXPort:nativeSetSerialPortParams > entering translate_date_bits > entering translate_stop_bits > leaving RXTXPort:translate_stop_bits > entering translate_parity > leaving translate_parity > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > ...REPEATS > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > leaving RXTXPort:nativeSetSerialPortParams > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > ...REPEATS > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > entering writeArray > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > writeArray() > leaving RXTXPort:writeArray > entering SerialImp.c:drain() > nativeDrain: trying tcdrain > RXTXPort:drain() returns: 0 > leaving RXTXPort:drain() > entering writeArray > writeArray() > leaving RXTXPort:writeArray > entering SerialImp.c:drain() > nativeDrain: trying tcdrain > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > Tue Apr 07 18:51:49 EDT 2009:TSerial[22]:Using Port:/dev/ttyUSB2 > Tue Apr 07 18:51:49 EDT 2009:TSerial[22].Transmit:TN > > Tue Apr 07 18:51:49 EDT 2009:TSerial[22].Transmit:RV > > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > ...REPEATS FOREVER? > > > Hi Bill ugh. The tiocmget... is the eventLoop checking for events. It sits with select() but has a timeout value to keep it spinning at a trivial rate. tcdrain() is the suspect. I don't see anything in the code that looks like a problem. If flow control is not enabled, I don't see a reason for it not to return. Given that this is USB, perhaps a message from the device got lost. Onboard UARTs would have a status register change when output buffer is empty. USB needs to communicate the event as an HID device which may be the source of the error. Dropping back to onboard UARTs eliminates that portion of the mix. What vendor/chipset is the USB dongle? I understand code has been pushed upon the linux serial devices for new for things like acpi. There very well could be a bug introduced. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Apr 7 18:38:22 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 7 Apr 2009 18:38:22 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49DB4212.40807@bbs.darktech.org> References: <49DB4212.40807@bbs.darktech.org> Message-ID: On Tue, 7 Apr 2009, cowwoc wrote: >> just two minor details, first about the errno change, I though >> >> #include >> extern int errno; >> >> is correct (POSIX.1) - why this change? > > If you compile this under Visual Studio 2008 you will get warnings that > the errno type being imported is different from the type being exported. > The definition I pasted is the one being exported. Perhaps we should use > #ifdef WIN32 for this? > Hi Gili, Perhaps a workaround for _MSVC is in order. GNU compilers for windows won't complain. If it's a question of MSVC or POSIX being right, the library favors the standard as a stated goal. I'm not sure what MSVC is using errno for but it should not be using it except with POSIX extensions. Perhaps #undef is enough to get rid of the warning and (maybe) has no ill consequences. Newer windows have POSIX extensions that may show how Microsoft solved the problem. It can probably fester. -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Tue Apr 7 19:54:06 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Tue, 07 Apr 2009 21:54:06 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: References: <49DB4212.40807@bbs.darktech.org> Message-ID: <49DC03BE.5010203@bbs.darktech.org> Trent Jarvi wrote: > I'm not sure what MSVC is using errno for but it should not be using it > except with POSIX extensions. Perhaps #undef is enough to get rid of > the warning and (maybe) has no ill consequences. Newer windows have > POSIX extensions that may show how Microsoft solved the problem. > > It can probably fester. What does "newer windows" refer to in this case? I was compiling using Visual Studio 2008 sp1 under Windows Vista. Both are cutting edge technologies as far as official releases go. I think you're best suited to judge whether this warning is a big deal or not so I think you should see it for yourself. Please try firing up Visual Studio 2008 (express?) against the project I sent you. Gili From Steffen.DETTMER at ingenico.com Wed Apr 8 05:50:42 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 8 Apr 2009 13:50:42 +0200 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49DC03BE.5010203@bbs.darktech.org> References: <49DB4212.40807@bbs.darktech.org> <49DC03BE.5010203@bbs.darktech.org> Message-ID: <20090408115042.GC5090@elberon.bln.de.ingenico.com> * cowwoc wrote on Tue, Apr 07, 2009 at 21:54 -0400: > Trent Jarvi wrote: > > I'm not sure what MSVC is using errno for but it should not be using it > > except with POSIX extensions. Perhaps #undef is enough to get rid of > > the warning and (maybe) has no ill consequences. Newer windows have > > POSIX extensions that may show how Microsoft solved the problem. I think here best is simply to omit this old^Wclassic `extern int errno;' line completely. I think standards just say something like `implementations may support the declaration extern int errno;'. About POSIX extensions I think in general it should be considered that althrough many things are available, even with MS Visual C++, the Microsoft tools lead developers to write non-portable code (and personally I think this is intentional). For example, they call the official ISO-C function `strerror' deprecated (!) and twaddle about some security enhancements (without even beeing specific). Someone could, because of this, lead to use the MS specific, unportable `strerror_s' instead. Even better, at _strerror_s they tell, for `ANSI compatiblity someone should use strerror_s'. Of course a program using [_]strerror_s won't be ANSI-C compliant. Do they mean strerror_r? _strerror_s has the same parameters - but of course in different order - to make porting a pain... SCNR. > What does "newer windows" refer to in this case? I was compiling using > Visual Studio 2008 sp1 under Windows Vista. Both are cutting edge > technologies as far as official releases go. `cutting edge technologies' yeah post-standard, portability-cutting technologies smoothing the way to MS world domination; own post-ANSI-C programming languages help (maybe to increase the share holder value)... SCNR. > I think you're best suited to judge whether this warning is a big deal > or not so I think you should see it for yourself. Please try firing up > Visual Studio 2008 (express?) against the project I sent you. yeah, getting the CL.EXE of 2008 running in a normal command line environment (without its special `C++ Shell') is a bit tricky - but possible. ;) oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From tjarvi at qbang.org Wed Apr 8 14:29:54 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 8 Apr 2009 14:29:54 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49DC03BE.5010203@bbs.darktech.org> References: <49DB4212.40807@bbs.darktech.org> <49DC03BE.5010203@bbs.darktech.org> Message-ID: The support has been around for a long time to. I don't know the details but the support appears to be tied to the OS. http://en.wikipedia.org/wiki/POSIX#POSIX_for_Windows On Tue, 7 Apr 2009, cowwoc wrote: > Trent Jarvi wrote: >> I'm not sure what MSVC is using errno for but it should not be using it >> except with POSIX extensions. Perhaps #undef is enough to get rid of the >> warning and (maybe) has no ill consequences. Newer windows have POSIX >> extensions that may show how Microsoft solved the problem. >> >> It can probably fester. > > What does "newer windows" refer to in this case? I was compiling > using Visual Studio 2008 sp1 under Windows Vista. Both are cutting edge > technologies as far as official releases go. > > I think you're best suited to judge whether this warning is a big > deal or not so I think you should see it for yourself. Please try firing up > Visual Studio 2008 (express?) against the project I sent you. > > Gili > From bill7007 at gmail.com Wed Apr 8 15:59:08 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Wed, 8 Apr 2009 17:59:08 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: <49D546F8.20807@gatworks.com> <49D693BA.8060909@gatworks.com> Message-ID: Hi Trent, I think I have hit on a work around but don't know why it works. The USB serial adapter is a "CableMAX" based on Prolific's PL2303. Backing out to the big picture, the application is old and has been very reliable until put on a new cpu and kernel. It only hangs sometimes say 25% and always at the same place, at tcdrain() on the flush() after the second write after startup. If it made it past this stage, all transmit and receive seemed reliable so it was like a startup timing issue. Since learning to debug kernel code is beyond my immediate priority, I took a shot at moving code around, adding delays, and such. I have found it good practice to do a flush after every write on streams like: outputStream.write(data.getBytes()); outputStream.flush(); If I remove the flush() after each write, the problem appears to go away! I don't think the flush is needed for a SerialOutputStream for this application anyway. Thanks for all the help, +BillJ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090408/35d96a9d/attachment-0007.html From bill7007 at gmail.com Thu Apr 9 09:20:11 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Thu, 9 Apr 2009 11:20:11 -0400 Subject: [Rxtx] Baud rate fixes in 2.2pre2 breaks 38400 on some Linux devices Message-ID: Hello, An application that worked at 38400 on a USB serial adapter (PL2303) using 2.1-7-r2 on Linux EL4 (and EL5) now fails using 2.2pre2. serialPort.setSerialPortParams(38400,SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); throws an unsupportedCommOperationException This problem matched a description of Bug 113and I posted a proposed patch there, but I don't understand the whole custom baud rate patch so it may need some thought. An older patch, [Rxtx] [Patch]: Baud Rate fixes try 1, testing encouraged., fixed some custom baud rates but apparently broke 38400 on some Linux device. Other baud rates seem to work OK. And, 38400 tested OK on local non-USB ports. My proposed patch probably breaks the custom baud rate patch since it was keyed on 38400 as a special case for Linux and my fix was to back out part of that patch, specifically: #if defined(TIOCGSERIAL) if ( cspeed == B38400 ) cspeed = 38400; #endif /* TIOCGSERIAL */ +BillJ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090409/5636af64/attachment-0006.html From cowwoc at bbs.darktech.org Fri Apr 10 08:38:49 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Fri, 10 Apr 2009 10:38:49 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: References: <49DB4212.40807@bbs.darktech.org> <49DC03BE.5010203@bbs.darktech.org> Message-ID: <49DF59F9.2050408@bbs.darktech.org> Doesn't Wikipedia list as an optional sub-system? Gili Trent Jarvi wrote: > > The support has been around for a long time to. I don't know the > details but the support appears to be tied to the OS. > > http://en.wikipedia.org/wiki/POSIX#POSIX_for_Windows > > On Tue, 7 Apr 2009, cowwoc wrote: > >> Trent Jarvi wrote: >>> I'm not sure what MSVC is using errno for but it should not be using >>> it except with POSIX extensions. Perhaps #undef is enough to get >>> rid of the warning and (maybe) has no ill consequences. Newer >>> windows have POSIX extensions that may show how Microsoft solved the >>> problem. >>> >>> It can probably fester. >> >> What does "newer windows" refer to in this case? I was compiling >> using Visual Studio 2008 sp1 under Windows Vista. Both are cutting >> edge technologies as far as official releases go. >> >> I think you're best suited to judge whether this warning is a big >> deal or not so I think you should see it for yourself. Please try >> firing up Visual Studio 2008 (express?) against the project I sent you. >> >> Gili >> From eranshuman at gmail.com Mon Apr 13 04:50:34 2009 From: eranshuman at gmail.com (Anshuman Srivastava) Date: Mon, 13 Apr 2009 16:20:34 +0530 Subject: [Rxtx] Send RTS /DTR signal Message-ID: <589913a50904130350n59cc51ffvbcd0a4eaefb4ce5f@mail.gmail.com> Hi, I want to send the RTS or DTR signal from the application Can anybody telll how to send the DTR /RTS signal using rxtxcomm libraries Thanks and regards -- Anshuman Srivastava "... in the end, it's not the years in your life that count. It's the life in your years." Buzz +91 9962515155 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090413/211b5ded/attachment-0003.html From ajmas at sympatico.ca Mon Apr 13 09:50:47 2009 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 13 Apr 2009 11:50:47 -0400 Subject: [Rxtx] Wiki Spam pages - need of captcha? Message-ID: Hi Trent, While checking for spam pages in the wiki I came across a page containing the following: "NOTICE: This page was created by a program as part of the Graffiti Network research project at Brown University. We have removed the data, but are unable to remove this page. We apologize for any inconveniences that our actions may have caused. For more information, please visit http://graffiti.cs.brown.edu/info/." Is there any chance we could add a captcha to account registration? Andr?-John From sguido at micromotive.net Mon Apr 13 09:46:15 2009 From: sguido at micromotive.net (Samuel Guido) Date: Mon, 13 Apr 2009 11:46:15 -0400 Subject: [Rxtx] Serial Output Stream Hangs on Windows Message-ID: <843C9F1C-72EE-4A40-B02A-3798EB0C57BF@micromotive.net> All, I am using RXTX in a small application to talk to a remote embedded device on a Windows host. All data is ASCII text. On physical comm ports, everything seems to be fine, messages are sent and received without much trouble. I am also trying to make the comm port selection automatic where I cycle through the available comm ports sending messages until I get the expected response. Unfortunately, when I query for the available comm ports, the bluetooth ports also show up. Whenever I try to send a string of characters to the bluetooth port, RXTX hangs way down in the call stack in the output stream, I believe in the DLL. I tried both the 2.1.7r2 and the 2.2pre2 releases and both have the same result. The send and receiving of messages from the comm port are in their own threads, but once the thread is blocked, I can't do anything with the comm ports since they are synchronized calls. The bluetooth ports are using a driver call "WIDCOMM" which I don't know who/what that is. This is on a IBM T42 laptop machine. Does anyone know what could be causing this? Is there a way to distinguish between bluetooth ports and physical comm ports? Please help, I am on a tight deadline and any help would greatly be appreciated. Thanks very much. Sam Guido From ajmas at sympatico.ca Mon Apr 13 11:04:24 2009 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 13 Apr 2009 13:04:24 -0400 Subject: [Rxtx] RxTX mentioned on Sun's Java Communications page Message-ID: Looks like RxTx gets some mention at Sun: Head over to the Java Communications page http://java.sun.com/products/javacomm/ and then click on Downloads and you get: " COMM API is a Java extension providing access to RS-232 serial ports and IEEE-1284 parallel ports (SPP mode). Sun Ray platform support is provided. Documentation and sample code are included, as well as interactive test utilities. API serial features provide access to: * Port settings (baud rate, parity, stop bits) * Port naming, mapping, enumeration (configurable) * Data transfer over TX, RX lines * DTR, CD, CTS, RTS and DSR signals * Hardware/Software flow-control * Receive-buffer threshold control * Asynchronous events indicating: * Data available on an RS-232 port * Port hardware line level changes * Port ownership changes within a JVM Update History: * javax.comm 3.0, Update 1 o Fixed problems locating and parsing portmap.conf * javax.comm 3.0, FCS o Redesigned portmapping and Sun Ray interoperability (see bundled documentation) * 2.0.3: o Added portmapping (comm.jar available 'as-is' for 3rd party native lib support)* Several Bugfixes to 2.0.3 (see bundled release notes) Note: Sun no longer offer's the Windows platform binaries of javax.comm, however javax.comm 2.0.3 can be used for the Windows platform, by using it in conjunction with the Win32 implementation layer provided by the RxTx project. To use that, download javax.comm for the 'generic' platform (which provides the front-end javax.comm API only, without platform specific back-end implementations bundled). Then acquire the Windows binary implementation rxtx-2.0.7pre1 from http://www.rxtx.org . " Looks like RxTx really is the closest thing we have to the 'official' implementation. From tjarvi at qbang.org Mon Apr 13 12:27:44 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 13 Apr 2009 12:27:44 -0600 (MDT) Subject: [Rxtx] RxTX mentioned on Sun's Java Communications page In-Reply-To: References: Message-ID: On Mon, 13 Apr 2009, Andre-John Mas wrote: > Looks like RxTx gets some mention at Sun: > > Head over to the Java Communications page http://java.sun.com/products/javacomm/ > and then click on Downloads and you get: > > " > COMM API is a Java extension providing access to RS-232 serial ports > and IEEE-1284 parallel ports (SPP mode). Sun Ray platform support is > provided. Documentation and sample code are included, as well as > interactive test utilities. API serial features provide access to: * > Port settings (baud rate, parity, stop bits) * Port naming, mapping, > enumeration (configurable) * Data transfer over TX, RX lines * DTR, > CD, CTS, RTS and DSR signals * Hardware/Software flow-control * > Receive-buffer threshold control * Asynchronous events indicating: * > Data available on an RS-232 port * Port hardware line level changes * > Port ownership changes within a JVM Update History: * javax.comm 3.0, > Update 1 o Fixed problems locating and parsing portmap.conf * > javax.comm 3.0, FCS o Redesigned portmapping and Sun Ray > interoperability (see bundled documentation) * 2.0.3: o Added > portmapping (comm.jar available 'as-is' for 3rd party native lib > support)* Several Bugfixes to 2.0.3 (see bundled release notes) Note: > Sun no longer offer's the Windows platform binaries of javax.comm, > however javax.comm 2.0.3 can be used for the Windows platform, by > using it in conjunction with the Win32 implementation layer provided > by the RxTx project. To use that, download javax.comm for the > 'generic' platform (which provides the front-end javax.comm API only, > without platform specific back-end implementations bundled). Then > acquire the Windows binary implementation rxtx-2.0.7pre1 from http://www.rxtx.org > .. > " > > Looks like RxTx really is the closest thing we have to the 'official' > implementation. Ugh. I don't know of any developer interest in maintaining rxtx 2.0. It would be cleaner for Sun to just openly take javax.comm for their Sun Ray project. If someone is interested in maintaining rxtx 2.0, don't be afraid to say so. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Mon Apr 13 16:04:19 2009 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 13 Apr 2009 17:04:19 -0500 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D8DDEB.5010908@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> Message-ID: <49E3B6E3.5050203@cox.net> cowwoc wrote: > Trent Jarvi wrote: >> You are responsible for cleaning up the serial ports when using threads. >> That said, if the thread did shut down, finalize should have been called >> if you are not passing the object around. See RXTXPort.java. >> >> protected void finalize() >> { >> if (debug) >> z.reportln( "RXTXPort:finalize()"); >> if( fd > 0 ) >> { >> if (debug) >> z.reportln( "RXTXPort:calling close()"); >> close(); >> } >> z.finalize(); >> } > > Two points: > > 1) One should never rely on finalizers because they may never run. A PhantomRef is the way to do this kind of cleanup in most cases. It will always fire. The real issue is that you have to understand that the on the Sun JVM, the GC can run finalization or advertise a dropped reference before an object is actually unreferenced in some cases. This happens, predominately in blocks of code where object references are short lived with no class member reference that the GC can find. When the JIT compiled code just references an object on the local stack and/or a register, the GC can prematurely attempt finalization/PhantomRef notification and result in bad things happening. The single solution to this problem is to use synchronize(obj){} at the end of the block of code that obj lives in, which keeps the object from getting reclaimed prematurely. For the sake of application sanity and recovery from erroneous code, it's almost always best to put resources like this into a map, accessed by name, and make an API method that lets you find the object by name, rather than by instance reference. Then, in your code, when you want to open a serial port, you'd do something like the following, which will close anything you already opened and then open it back up. Map ports = ...; public void closePort( String port ) { CommPort p = null; p = ports.remove(port); if( p != null ) p.close(); } public CommPort public CommPort openPort( String port, String user, int timeout ) throws IOException { closePort( port ); CommPort p = CommPortIdentifier.getPortIdentifier(port). open( user, timeout ); ports.put( port, p ); return p; } Appropriate use of synchronized(ports) may be necessary if ports is not referencing a concurrency safe Map implementation such as Hashtable or ConcurrentHashMap. Gregg Wonderly From gergg at cox.net Mon Apr 13 16:36:57 2009 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 13 Apr 2009 17:36:57 -0500 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: <49D546F8.20807@gatworks.com> <49D693BA.8060909@gatworks.com> Message-ID: <49E3BE89.4020402@cox.net> Check CTS/RTS and DTR/CD etc on the device to make sure you haven't hung the kernel trying to clean up something, but it's now waiting for CTS etc. In general, you should be careful about using HW flow control when cables can be trivially unplugged or broken. Use application layer checksums or similar things to make sure data that is flowing is sane and that buffers have not overrun, resulting in lost data. Gregg Wonderly Trent Jarvi wrote: > UTS_RELEASE is defined in now. The check really should > be removed from RXTX. It was a defensive check for wilder times when GNU > glibc did not have defines the kernel headers had so rxtx would include > the kernel headers instead. :/ > > If you don't have linux/version.h, it is generated when you configure the > kernel. make oldconfig used to do the trick. It may make sense to work > with the prerelease or CVS code. > > RXTX just assumes that flush, read and anything else the kernel exposes > may be called at anytime from any thread. There isn't a design for the > kernel interaction. There are higher level constraints put in Java to > prevent some things happening at the same time with 'synchronized.' > RXTXPort.java has all of those. > > When the port is opened, a native event thread is started which uses > select to know if an event has happened. > > BSD like systems have a native thread that fires off on write which tries > to flush() to determine when the output buffer is empty asynchronously. > > The rest is not marshaled in any fashion at the native level. T > > I think there is a lower level deadlock being triggered in flush as well. > I don't think it should be possible if everything was right underneath us. > You may want to examine the java code closer to make sure it isnt possible > the lock is there. > > > On Mon, 6 Apr 2009, Bill Johnson wrote: > >> Once it hung, three stack dumps minutes apart were exactly the same. >> I have a noticed that when it hangs, the read appears after flush() enter and >> before flush leave() that doesn't happen like: >> RXTXPort:SerialOutputStream:flush() enter >> RXTXPort:SerialInputStream:read(8192 0 8192) called >> >> When it works, flush() enter and leave happen together. It may just be because >> flush() hangs and read is the only other thread waiting to run at that point. >> I don't know much about the RXTX design and kernel interaction, just digging >> through the code some. Is there a design description somewhere? >> >> Am hung up on target system compile since UTS_RELEASE seems no longer defined for >> 2.6.18 up kernels and have not figured a good patch yet. But, that is another >> issue. >> >> Thanks for the good help. >> >> >> On Fri, Apr 3, 2009 at 6:54 PM, U. George wrote: >> I would have tried 2 or 3 "^\" . If things are stuck, then all will be >> at same 'java' instruction. If thread is moving, then one of the >> snapshots would be different. >> >> I *think* flushing/draining wont return until the kernel buffers to >> device have been accepted by device. Stuck/paused device? >> >> >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From cowwoc at bbs.darktech.org Mon Apr 13 20:41:20 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Mon, 13 Apr 2009 22:41:20 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49E3B6E3.5050203@cox.net> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49E3B6E3.5050203@cox.net> Message-ID: <49E3F7D0.5090207@bbs.darktech.org> Gregg Wonderly wrote: > A PhantomRef is the way to do this kind of cleanup in most cases. It > will always fire. The real issue is that you have to understand that > the on the Sun JVM, the GC can run finalization or advertise a dropped > reference before an object is actually unreferenced in some cases. This > happens, predominately in blocks of code where object references are > short lived with no class member reference that the GC can find. When > the JIT compiled code just references an object on the local stack > and/or a register, the GC can prematurely attempt > finalization/PhantomRef notification and result in bad things happening. I've never seen this myself. Can you reproduce it on the latest JRE? If so, this sounds like a bug to me and should be fixed. Please consider filing a bug report and telling me the bug number. I'll try running it by my Sun contacts. Gili From ferry_new2004 at yahoo.com Mon Apr 13 21:24:59 2009 From: ferry_new2004 at yahoo.com (Ferry Sumendap) Date: Mon, 13 Apr 2009 20:24:59 -0700 (PDT) Subject: [Rxtx] In Linux, RXTX serial port lib cannot send character which hex is more than 127. Message-ID: <30875.39589.qm@web33106.mail.mud.yahoo.com> Hello everybody, I have just tested the RXTXserial port library version RXTX2-1-7pre20 to send two characters which are character ascii 230 and 234. It seems that the driver somehow did not send the two characters into serial port if the Operating System is Linux Mandriva 2007 (kernel version 2.6.17-13mdv ) or Linux Mandriva 2009. I also tried the driver using same java code (java class file of the program I wrote), in Windows XP, it does work. Should I configure something (special configuration in Linux) or did I miss something ? I also have tested the latest RXTX 2.2pre2 driver, but it still have that problem. Regards, Ferry -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090413/94fdfbea/attachment-0002.html From tjarvi at qbang.org Mon Apr 13 22:01:04 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 13 Apr 2009 22:01:04 -0600 (MDT) Subject: [Rxtx] In Linux, RXTX serial port lib cannot send character which hex is more than 127. In-Reply-To: <30875.39589.qm@web33106.mail.mud.yahoo.com> References: <30875.39589.qm@web33106.mail.mud.yahoo.com> Message-ID: On Mon, 13 Apr 2009, Ferry Sumendap wrote: > Hello everybody, > > I have just tested the RXTXserial port library version? RXTX2-1-7pre20 to > send two characters which are character ascii? 230 and 234. It seems that > the driver somehow did not send the two characters into serial port if the > Operating System is Linux Mandriva 2007 (kernel version 2.6.17-13mdv > ) or Linux Mandriva 2009. > I also tried the driver using? same java code (java class file of the > program I wrote), in Windows XP,? it does work. > > Should I configure something (special configuration in Linux)? or did I miss > something ? > I also have tested the latest RXTX 2.2pre2 driver, but it still have that > problem. > Hello Ferry This sounds like an unlikely problem. Even with USB dongle issues, I can't think of a reason that would be a problem. Is this a connection at 9600 8N1? Sometimes it really is the cable. -- Trent Jarvi tjarvi at qbang.org From ferry_new2004 at yahoo.com Mon Apr 13 22:15:04 2009 From: ferry_new2004 at yahoo.com (Ferry Sumendap) Date: Mon, 13 Apr 2009 21:15:04 -0700 (PDT) Subject: [Rxtx] Fw: In Linux, RXTX serial port lib cannot send character which hex is more than 127. Message-ID: <948418.50805.qm@web33103.mail.mud.yahoo.com> ----- Forwarded Message ---- From: Ferry Sumendap To: Trent Jarvi Sent: Tuesday, April 14, 2009 11:10:04 AM Subject: Re: [Rxtx] In Linux, RXTX serial port lib cannot send character which hex is more than 127. Thank you for your answer. I use the same machine, cable and devices to test. My PC is installed with Linux Mandriva and WINDOWS. The serial port physically have no problem since using Windows, it works. I also tested the serial port using MONI (tcl based program). MONI is linux based program to send some characters to serial port. Using MONI, I sent the characters to /dev/ttyS0, and it works because the device which is plugged in /dev/ttyS0 received and answered the message. But for RXTX, some how, java based program cannot send those characters. With the same java based program, it works properly in WINDOWS and the same cable, devices, hardware specification. That's why I am curious about RXTX. Here is the serial port configuration I used. Com Port /dev/ttyS0 Baud rate 19200 Data bits 8 ( value = 8) Stop bits 1 ( value = 1) Parity None ( value = 0) Thank you very much for your response. Regards, Ferry ________________________________ From: Trent Jarvi To: Ferry Sumendap Cc: rxtx at qbang.org Sent: Tuesday, April 14, 2009 11:01:04 AM Subject: Re: [Rxtx] In Linux, RXTX serial port lib cannot send character which hex is more than 127. On Mon, 13 Apr 2009, Ferry Sumendap wrote: > Hello everybody, > > I have just tested the RXTXserial port library version RXTX2-1-7pre20 to > send two characters which are character ascii 230 and 234. It seems that > the driver somehow did not send the two characters into serial port if the > Operating System is Linux Mandriva 2007 (kernel version 2.6.17-13mdv > ) or Linux Mandriva 2009. > I also tried the driver using same java code (java class file of the > program I wrote), in Windows XP, it does work. > > Should I configure something (special configuration in Linux) or did I miss > something ? > I also have tested the latest RXTX 2.2pre2 driver, but it still have that > problem. > Hello Ferry This sounds like an unlikely problem. Even with USB dongle issues, I can't think of a reason that would be a problem. Is this a connection at 9600 8N1? Sometimes it really is the cable. -- Trent Jarvi tjarvi at qbang.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090413/27a37ea5/attachment-0002.html From ferry_new2004 at yahoo.com Mon Apr 13 22:23:53 2009 From: ferry_new2004 at yahoo.com (Ferry Sumendap) Date: Mon, 13 Apr 2009 21:23:53 -0700 (PDT) Subject: [Rxtx] In Linux, RXTX serial port lib cannot send character which hex is more than 127. In-Reply-To: References: <30875.39589.qm@web33106.mail.mud.yahoo.com> <81465.86461.qm@web33102.mail.mud.yahoo.com> Message-ID: <736778.48214.qm@web33108.mail.mud.yahoo.com> I am sorry not telling you about the configuration.. Yes I did test using the same serial port configuration, but the RXTX did not work properly. I also use "root" just in case there is security violation. If I sent another character that is below 127 (ascii < 127) the RXTX works properly either in LINUX or WINDOWS. I also cannot believe that coders of RXTX would make diffentiation between baudrate 19200 and 9600. The driver actually works very good unfortunately if the character is upper than ascii 127 (like ascii 230 and 234) it will not work. Thank you very much. Regards, Ferry ________________________________ From: Trent Jarvi To: Ferry Sumendap Cc: Trent Jarvi Sent: Tuesday, April 14, 2009 11:16:34 AM Subject: Re: [Rxtx] In Linux, RXTX serial port lib cannot send character which hex is more than 127. Hi Ferry, The only thing you mention that is not tested on a regular basis is the 19200 baudrate. There is nothing special (code wise) about that baudrate. On Mon, 13 Apr 2009, Ferry Sumendap wrote: > Thank you for your answer. > > I use the same machine, cable and devices to test. > My PC is installed with Linux Mandriva and WINDOWS. > The serial port physically have no problem since using Windows, it works. > > I also tested the serial port using MONI (tcl based program). > MONI is linux based program to send some characters to serial port. > Using MONI, I sent the characters to /dev/ttyS0, and it works because the > device which is plugged in /dev/ttyS0 received and answered the message. > > But for RXTX, some how, java based program cannot send those characters. > With the same java based program, it works properly in WINDOWS and the same > cable, devices, hardware specification. > That's why I am curious about RXTX. > > > > Here is the serial port configuration I used. > > Com Port /dev/ttyS0 > Baud rate 19200 > Data bits 8 ( value = 8) > Stop bits 1 ( value = 1) > Parity None ( value = 0) > > > > Thank you very much for your response. > > Regards, > Ferry > > > ____________________________________________________________________________ > From: Trent Jarvi > To: Ferry Sumendap > Cc: rxtx at qbang.org > Sent: Tuesday, April 14, 2009 11:01:04 AM > Subject: Re: [Rxtx] In Linux, RXTX serial port lib cannot send character > which hex is more than 127. > > > > On Mon, 13 Apr 2009, Ferry Sumendap wrote: > > > Hello everybody, > > > > I have just tested the RXTXserial port library version RXTX2-1-7pre20 to > > send two characters which are character ascii 230 and 234. It seems that > > the driver somehow did not send the two characters into serial port if the > > Operating System is Linux Mandriva 2007 (kernel version 2.6.17-13mdv > > ) or Linux Mandriva 2009. > > I also tried the driver using same java code (java class file of the > > program I wrote), in Windows XP, it does work. > > > > Should I configure something (special configuration in Linux) or did I > miss > > something ? > > I also have tested the latest RXTX 2.2pre2 driver, but it still have that > > problem. > > > > Hello Ferry > > This sounds like an unlikely problem. > > Even with USB dongle issues, I can't think of a reason that would be a > problem. Is this a connection at 9600 8N1? > > Sometimes it really is the cable. > > -- > Trent Jarvi > tjarvi at qbang.org > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090413/7a2fd5a0/attachment-0002.html From tjarvi at qbang.org Mon Apr 13 22:45:09 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 13 Apr 2009 22:45:09 -0600 (MDT) Subject: [Rxtx] In Linux, RXTX serial port lib cannot send character which hex is more than 127. In-Reply-To: <736778.48214.qm@web33108.mail.mud.yahoo.com> References: <30875.39589.qm@web33106.mail.mud.yahoo.com> <81465.86461.qm@web33102.mail.mud.yahoo.com> <736778.48214.qm@web33108.mail.mud.yahoo.com> Message-ID: This sounds like a signed vs unsigned char issue. Given that rxtx does binary read and write fine on Linux, I'm at a loss of what your problem may be. No, I don't suspect the baudrate is an issue either. On Mon, 13 Apr 2009, Ferry Sumendap wrote: > I am sorry not telling you about the configuration.. > > Yes I did test using the same serial port configuration, but the RXTX did > not work properly. > I also use "root" just in case there is security violation. > If? I sent another character that is below 127 (ascii < 127) the RXTX works > properly either in LINUX or WINDOWS. > > I also cannot believe that coders of RXTX would make diffentiation between > baudrate 19200 and 9600. > The driver actually works very good unfortunately if the character is upper > than ascii 127 (like ascii 230 and 234) it will not work. > > Thank you very much. > Regards, > > Ferry > > ____________________________________________________________________________ > From: Trent Jarvi > To: Ferry Sumendap > Cc: Trent Jarvi > Sent: Tuesday, April 14, 2009 11:16:34 AM > Subject: Re: [Rxtx] In Linux, RXTX serial port lib cannot send character > which hex is more than 127. > > > Hi Ferry, > > The only thing you mention that is not tested on a regular basis is the > 19200 baudrate.? There is nothing special (code wise) about that baudrate. > > On Mon, 13 Apr 2009, Ferry Sumendap wrote: > > > Thank you for your answer. > > > > I use the same machine, cable and devices to test. > > My PC is installed with Linux Mandriva and WINDOWS. > > The serial port physically have no problem since using Windows, it works. > > > > I also tested the serial port using MONI (tcl based program). > > MONI is linux based program to send some characters to serial port. > > Using MONI, I sent the characters to /dev/ttyS0, and it works because the > > device which is plugged in /dev/ttyS0 received and answered the message. > > > > But for RXTX, some how, java based program cannot send those characters. > > With the same java based program, it works properly in WINDOWS and the > same > > cable, devices, hardware specification. > > That's why I am curious about RXTX. > > > > > > > > Here is the serial port configuration I used. > > > > Com Port /dev/ttyS0 > > Baud rate 19200 > > Data bits 8 ( value = 8) > > Stop bits 1?? ( value = 1) > > Parity None? ( value = 0) > > > > > > > > Thank you very much for your response. > > > > Regards, > > Ferry > > > > > >___________________________________________________________________________ > _ > > From: Trent Jarvi > > To: Ferry Sumendap > > Cc: rxtx at qbang.org > > Sent: Tuesday, April 14, 2009 11:01:04 AM > > Subject: Re: [Rxtx] In Linux, RXTX serial port lib cannot send character > > which hex is more than 127. > > > > > > > > On Mon, 13 Apr 2009, Ferry Sumendap wrote: > > > > > Hello everybody, > > > > > > I have just tested the RXTXserial port library version? RXTX2-1-7pre20 > to > > > send two characters which are character ascii? 230 and 234. It seems > that > > > the driver somehow did not send the two characters into serial port if > the > > > Operating System is Linux Mandriva 2007 (kernel version 2.6.17-13mdv > > > ) or Linux Mandriva 2009. > > > I also tried the driver using? same java code (java class file of the > > > program I wrote), in Windows XP,? it does work. > > > > > > Should I configure something (special configuration in Linux)? or did I > > miss > > > something ? > > > I also have tested the latest RXTX 2.2pre2 driver, but it still have > that > > > problem. > > > > > > > Hello Ferry > > > > This sounds like an unlikely problem. > > > > Even with USB dongle issues, I can't think of a reason that would be a > > problem.? Is this a connection at 9600 8N1? > > > > Sometimes it really is the cable. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > > > > > > > > From ilkka at myller.com Mon Apr 13 23:12:16 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 14 Apr 2009 08:12:16 +0300 Subject: [Rxtx] In Linux, RXTX serial port lib cannot send character which hex is more than 127. In-Reply-To: References: <30875.39589.qm@web33106.mail.mud.yahoo.com> <81465.86461.qm@web33102.mail.mud.yahoo.com> <736778.48214.qm@web33108.mail.mud.yahoo.com> Message-ID: Hi, Another suggestion: incorrect java byte casting. Java byte type has a range from -128 to 127. I've seen people assume range of 0 - 255. Incorrect integer casting with bytes is a common mistake is to cause those >127 ascii issues. Could it be? (int)b versus (int)(b & 0xFF) -- I Trent Jarvi kirjoitti 14.4.2009 kello 7.45: > > This sounds like a signed vs unsigned char issue. Given that rxtx > does binary read and write fine on Linux, I'm at a loss of what your > problem may be. > > No, I don't suspect the baudrate is an issue either. > > On Mon, 13 Apr 2009, Ferry Sumendap wrote: > >> I am sorry not telling you about the configuration.. >> Yes I did test using the same serial port configuration, but the >> RXTX did >> not work properly. >> I also use "root" just in case there is security violation. >> If I sent another character that is below 127 (ascii < 127) the >> RXTX works >> properly either in LINUX or WINDOWS. >> I also cannot believe that coders of RXTX would make diffentiation >> between >> baudrate 19200 and 9600. >> The driver actually works very good unfortunately if the character >> is upper >> than ascii 127 (like ascii 230 and 234) it will not work. >> Thank you very much. >> Regards, >> Ferry >> ____________________________________________________________________________ >> From: Trent Jarvi >> To: Ferry Sumendap >> Cc: Trent Jarvi >> Sent: Tuesday, April 14, 2009 11:16:34 AM >> Subject: Re: [Rxtx] In Linux, RXTX serial port lib cannot send >> character >> which hex is more than 127. >> Hi Ferry, >> The only thing you mention that is not tested on a regular basis is >> the >> 19200 baudrate. There is nothing special (code wise) about that >> baudrate. >> On Mon, 13 Apr 2009, Ferry Sumendap wrote: >> > Thank you for your answer. >> > >> > I use the same machine, cable and devices to test. >> > My PC is installed with Linux Mandriva and WINDOWS. >> > The serial port physically have no problem since using Windows, >> it works. >> > >> > I also tested the serial port using MONI (tcl based program). >> > MONI is linux based program to send some characters to serial port. >> > Using MONI, I sent the characters to /dev/ttyS0, and it works >> because the >> > device which is plugged in /dev/ttyS0 received and answered the >> message. >> > >> > But for RXTX, some how, java based program cannot send those >> characters. >> > With the same java based program, it works properly in WINDOWS >> and the >> same >> > cable, devices, hardware specification. >> > That's why I am curious about RXTX. >> > >> > >> > >> > Here is the serial port configuration I used. >> > >> > Com Port /dev/ttyS0 >> > Baud rate 19200 >> > Data bits 8 ( value = 8) >> > Stop bits 1 ( value = 1) >> > Parity None ( value = 0) >> > >> > >> > >> > Thank you very much for your response. >> > >> > Regards, >> > Ferry >> > >> > >> > >> ___________________________________________________________________________ >> _ >> > From: Trent Jarvi >> > To: Ferry Sumendap >> > Cc: rxtx at qbang.org >> > Sent: Tuesday, April 14, 2009 11:01:04 AM >> > Subject: Re: [Rxtx] In Linux, RXTX serial port lib cannot send >> character >> > which hex is more than 127. >> > >> > >> > >> > On Mon, 13 Apr 2009, Ferry Sumendap wrote: >> > >> > > Hello everybody, >> > > >> > > I have just tested the RXTXserial port library version >> RXTX2-1-7pre20 >> to >> > > send two characters which are character ascii 230 and 234. It >> seems >> that >> > > the driver somehow did not send the two characters into serial >> port if >> the >> > > Operating System is Linux Mandriva 2007 (kernel version >> 2.6.17-13mdv >> > > ) or Linux Mandriva 2009. >> > > I also tried the driver using same java code (java class file >> of the >> > > program I wrote), in Windows XP, it does work. >> > > >> > > Should I configure something (special configuration in Linux) >> or did I >> > miss >> > > something ? >> > > I also have tested the latest RXTX 2.2pre2 driver, but it still >> have >> that >> > > problem. >> > > >> > >> > Hello Ferry >> > >> > This sounds like an unlikely problem. >> > >> > Even with USB dongle issues, I can't think of a reason that would >> be a >> > problem. Is this a connection at 9600 8N1? >> > >> > Sometimes it really is the cable. >> > >> > -- >> > Trent Jarvi >> > tjarvi at qbang.org >> > >> > >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From sunil at saltriver.com Tue Apr 14 01:06:38 2009 From: sunil at saltriver.com (Sunil Bhambani) Date: Tue, 14 Apr 2009 07:06:38 -0000 Subject: [Rxtx] RxTx on Mac for USB Message-ID: <1080422816.3127.6.camel@localhost.localdomain> Hi, I have a GPS device which is USB device. I want to use that device on Mac System and Java as the programming language. I have read that USB support through RxTx on Mac is not there. Is this correct? I would like to read the data that comes to GPS device. Can some connector be used to communicate with that device. For example USB to RJ11 or USB to serial connector? Are this connectors reliable enough to be used? Hope to get the reply soon. -- Thank & Regards Sunil -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090414/295ccb1d/attachment-0001.html From helgeingvart at gmail.com Tue Apr 14 01:43:04 2009 From: helgeingvart at gmail.com (Helge Fredriksen) Date: Tue, 14 Apr 2009 09:43:04 +0200 Subject: [Rxtx] IO exceptions on 2.2pre2 In-Reply-To: References: <306B677E-9207-44CB-81CD-787A50DB7DA6@myller.com> Message-ID: FYI: There seem to be success on this problem by switching to your commercial counterpart from SerialIO (http://www.serialio.com). A FTDI only problem? Best regards, Helge Fredriksen On Sat, Mar 28, 2009 at 5:32 PM, Helge Fredriksen wrote: > Thanks for your suggestions, > > We have tried switching off the power saving settings as recommended, but > regrettably we see the same things happening still. > > The FTDI device is not connected directly to USB hubs, no. > > Someone have any more ideas? > > Best regards, > Helge Fredriksen > > > On Tue, Mar 24, 2009 at 9:27 AM, Ilkka Myller wrote: > >> Hi Helge, >> >> I am not sure if this will help, but you could try this: >> >> echo on > /sys/bus/usb/devices//power/level >> echo 0 > /sys/bus/usb/devices//power/autosuspend >> >> is the USB-bus device id of your FTDI adapter (bus-device, for >> example "2-2") >> >> This will disable USB power saving/autosuspend of FTDI USB-device. >> I've seen some some systems where this helps with FTDI-adapter connection >> drops. >> >> Also: is your FTDI device directly connected to PC's USB root hub? If not, >> test that too. >> >> >> -- >> I >> >> (replace with the usb bus device id of your FTDI serial >> adapter) >> >> Helge Fredriksen kirjoitti 24.3.2009 kello 9.45: >> >> Hello! >> >> Here's the device details: >> >> FT232R is a USB to serial UART interface. >> >> Link to componentt: http://www.ftdichip.com/Products/FT232R.htm >> >> Regards, >> Helge Fredriksen >> >> On Tue, Mar 24, 2009 at 12:05 AM, Trent Jarvi wrote: >> >>> >>> >>> On Mon, 23 Mar 2009, Helge Fredriksen wrote: >>> >>> Hello again. >>>> >>>> I'm having a bit trouble with the 2.2pre2 version it seems. I'm having >>>> an >>>> application running on Ubuntu 8.10 that seem to run stable but after an >>>> hour >>>> or so the application breaks down with lot's of IO exceptions like this: >>>> >>>> java.io.IOException: Input/output error in nativeavailable >>>> at gnu.io.RXTXPort.nativeavailable(Native Method) >>>> at gnu.io.RXTXPort$SerialInputStream.available(RXTXPort.java:1596) >>>> >>>> atcom.poseidon.usb.UsbInterface$MySerialPortEventListener.serialEvent(UsbInte >>>> rface.java:251) >>>> at gnu.io.RXTXPort.sendEvent(RXTXPort.java:772) >>>> at gnu.io.RXTXPort.eventLoop(Native Method) >>>> at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1641) >>>> >>>> Any ideas? >>>> >>> >>> Hi Helge, >>> >>> It sounds like the file descriptor (USB driver) is in an invalid state. >>> >>> What can you tell us about the USB dongle? Is it bluetooth? Do you know >>> what chipset is in it? >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090414/e2c97c4f/attachment-0002.html From Steffen.DETTMER at ingenico.com Tue Apr 14 02:21:35 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 14 Apr 2009 10:21:35 +0200 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49E3F7D0.5090207@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49E3B6E3.5050203@cox.net> <49E3F7D0.5090207@bbs.darktech.org> Message-ID: <20090414082135.GG5090@elberon.bln.de.ingenico.com> * cowwoc wrote on Mon, Apr 13, 2009 at 22:41 -0400: > Gregg Wonderly wrote: > > The real issue is that you have to understand that > > the on the Sun JVM, the GC can run finalization or advertise a dropped > > reference before an object is actually unreferenced in some cases. > > I've never seen this myself. Can you reproduce it on the latest JRE? If > so, this sounds like a bug to me and should be fixed. Please consider > filing a bug report and telling me the bug number. I'll try running it > by my Sun contacts. I found some general hints here: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2261.html Traditional finalization in garbage collected languages is defined in terms of object reachability. But objects can easily become "unreachable" earlier than the programmer expects, due to compiler optimizations. An object may be logically in use long past the last point at which the memory associated with the object is accessed or referenced by any pointers visible to the garbage collector. In the worst case, the compiler might decide to store all the fields of an object in registers, and then observe that the "this" pointer for the newly allocated memory is dead immediately after the allocation, and hence not save it anywhere. The garbage collector, even if run immediately after the allocation, would then discover that the memory object is no longer reachable, and run the finalizer immediately, in spite of the fact that the object fields are still in use, and in fact may remain in use after the finalizer has run. However, if this would be a so general weakness that someone is adviced to store object instances in collections instead of using members or having the references on the stack - even if used correctly - I think it would be a major weakness which probably had been fixed, because otherwise raping collections as such workarounds would be commonly visible. BTW, I think the citation above is wrong if the optimised member values are used after that. The destructor / finalizer may set all fields to null or so and (ordinary) optimizers should not affect the behavior of correct and usual code I think. (ohh, and Cowwoc, forced-GC and to forbid the developer to control lifecycle in Java is considered a feature, not a bug! -- SCNR) oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From michael.erskine at ketech.com Tue Apr 14 02:50:53 2009 From: michael.erskine at ketech.com (Michael Erskine) Date: Tue, 14 Apr 2009 09:50:53 +0100 Subject: [Rxtx] Wiki Spam pages - need of captcha? In-Reply-To: References: Message-ID: <06BA3262D918014F9183B66425D5A8D45FA42D88FB@no-sv-03.ketech.local> All, See http://tech.slashdot.org/article.pl?sid=09/04/13/0120226 for details of this particular use of open wiki sites and the apology. Regards, Michael Erskine. From Steffen.DETTMER at ingenico.com Tue Apr 14 04:27:53 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 14 Apr 2009 12:27:53 +0200 Subject: [Rxtx] In Linux, RXTX serial port lib cannot send character which hex is more than 127. In-Reply-To: <30875.39589.qm@web33106.mail.mud.yahoo.com> References: <30875.39589.qm@web33106.mail.mud.yahoo.com> Message-ID: <20090414102753.GI5090@elberon.bln.de.ingenico.com> * Ferry Sumendap wrote on Mon, Apr 13, 2009 at 20:24 -0700: > I have just tested the RXTXserial port library version > RXTX2-1-7pre20 to send two characters which are character ascii > 230 and 234. Can you send -26 and -22 instead? Then it probably is a casting issue (as Trent and Ilkka already considered). oki, Steffen End of message. ------------------------------------------------------------------->8======= About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Bob_Jacobsen at lbl.gov Tue Apr 14 08:31:13 2009 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Tue, 14 Apr 2009 07:31:13 -0700 Subject: [Rxtx] RxTx on Mac for USB In-Reply-To: <1080422816.3127.6.camel@localhost.localdomain> References: <1080422816.3127.6.camel@localhost.localdomain> Message-ID: At 2:56 AM +0530 3/28/04, Sunil Bhambani wrote: >Hi, > >I have a GPS device which is USB device. I want to use that device >on Mac System and Java as the programming language. I have read that >USB support through RxTx on Mac is not there. Is this correct? I >would like to read the data that comes to GPS device. Can some >connector be used to communicate with that device. For example USB >to RJ11 or USB to serial connector? Are this connectors reliable >enough to be used? If the GPS device looks like a serial device to Mac OS X (Darwin), RXTX will work fine. To check: *) Unplug your device. *) Do the following command line, and keep the output: ls -lt /dev/ | head -10 *) Plug in your device and wait a couple seconds *) Repeat the above command line, and see if there are any new entries at the top of the output. The new entries, if any, are how your GPS device was mounted. If the new device(s) start with /dev/tty or /dev/cu, you'll be able to use RXTX. As a next step, you can use the "cu" command to try to talk to your GPS device as serial device. For example, cu -s 19200 -l /dev/tty.usbserial-LWPMMU13 You can download RXTX installers for various MacOS X version from here: But note these are for RXTX 2.0 versions (javax.comm package). Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From sunil at saltriver.com Wed Apr 15 00:06:40 2009 From: sunil at saltriver.com (Sunil Bhambani) Date: Wed, 15 Apr 2009 06:06:40 -0000 Subject: [Rxtx] RxTx on Mac for USB In-Reply-To: References: <1080422816.3127.6.camel@localhost.localdomain> Message-ID: <1080505612.2924.9.camel@localhost.localdomain> On Tue, 2009-04-14 at 07:31 -0700, Bob Jacobsen wrote: > At 2:56 AM +0530 3/28/04, Sunil Bhambani wrote: > >Hi, > > > >I have a GPS device which is USB device. I want to use that device > >on Mac System and Java as the programming language. I have read that > >USB support through RxTx on Mac is not there. Is this correct? I > >would like to read the data that comes to GPS device. Can some > >connector be used to communicate with that device. For example USB > >to RJ11 or USB to serial connector? Are this connectors reliable > >enough to be used? > > If the GPS device looks like a serial device to Mac OS X (Darwin), > RXTX will work fine. > > To check: > > *) Unplug your device. > *) Do the following command line, and keep the output: > > ls -lt /dev/ | head -10 > > *) Plug in your device and wait a couple seconds > > *) Repeat the above command line, and see if there are any new > entries at the top of the output. > > The new entries, if any, are how your GPS device was mounted. If the > new device(s) start with /dev/tty or /dev/cu, you'll be able to use > RXTX. > > As a next step, you can use the "cu" command to try to talk to your > GPS device as serial device. For example, > > cu -s 19200 -l /dev/tty.usbserial-LWPMMU13 > > You can download RXTX installers for various MacOS X version from here: > > > > But note these are for RXTX 2.0 versions (javax.comm package). > > Bob Hi Bob, I am using Mac 10.5 and I have done what you have said. I get the following output total 4 crw--w---- 1 Saltriver tty 16, 0 Apr 15 11:13 ttys000 crw-rw-rw- 1 root wheel 8, 0 Apr 15 11:13 random crw-rw-rw- 1 root tty 15, 1 Apr 15 11:13 ptmx crw------- 1 Saltriver staff 0, 0 Apr 15 11:10 console crw-rw-rw- 1 root wheel 3, 2 Apr 15 10:58 null crw------- 1 root wheel 23, 1 Apr 15 10:32 bpf1 crw------- 1 root wheel 23, 0 Apr 15 10:32 bpf0 crw------- 1 root wheel 11, 0 Apr 15 10:31 autofs crw------- 1 root wheel 17, 0 Apr 15 10:31 autofs_control saltriver-infosystemss-mac-mini:~ Saltriver$ ls -lt /dev/ | head -10 total 4 crw--w---- 1 Saltriver tty 16, 0 Apr 15 11:16 ttys000 crw-rw-rw- 1 root tty 15, 1 Apr 15 11:16 ptmx crw-rw-rw- 1 root wheel 8, 0 Apr 15 11:13 random crw------- 1 Saltriver staff 0, 0 Apr 15 11:10 console crw-rw-rw- 1 root wheel 3, 2 Apr 15 10:58 null crw------- 1 root wheel 23, 1 Apr 15 10:32 bpf1 crw------- 1 root wheel 23, 0 Apr 15 10:32 bpf0 crw------- 1 root wheel 11, 0 Apr 15 10:31 autofs crw------- 1 root wheel 17, 0 Apr 15 10:31 autofs_control I think the output is same in both. Is there any way of mounting that device. I am very new to Mac. I am using RXTX 2.1 without javax.comm package. I have tried the same code in fedora and it ran successfully. I have tried inserting pen drive in the USB port and it was detected. Hope to get a quick reply from you. Thanks & Regards Sunil -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090415/19e599e5/attachment.html From Bob_Jacobsen at lbl.gov Wed Apr 15 03:43:26 2009 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Wed, 15 Apr 2009 02:43:26 -0700 Subject: [Rxtx] RxTx on Mac for USB In-Reply-To: <1080505612.2924.9.camel@localhost.localdomain> References: <1080422816.3127.6.camel@localhost.localdomain> <1080505612.2924.9.camel@localhost.localdomain> Message-ID: At 1:56 AM +0530 3/29/04, Sunil Bhambani wrote: > >I am using Mac 10.5 and I have done what you have said. I get the >following output > >total 4 >crw--w---- 1 Saltriver tty 16, 0 Apr 15 11:13 ttys000 >crw-rw-rw- 1 root wheel 8, 0 Apr 15 11:13 random >crw-rw-rw- 1 root tty 15, 1 Apr 15 11:13 ptmx >crw------- 1 Saltriver staff 0, 0 Apr 15 11:10 console ... >saltriver-infosystemss-mac-mini:~ Saltriver$ ls -lt /dev/ | head -10 >total 4 >crw--w---- 1 Saltriver tty 16, 0 Apr 15 11:16 ttys000 >crw-rw-rw- 1 root tty 15, 1 Apr 15 11:16 ptmx >crw-rw-rw- 1 root wheel 8, 0 Apr 15 11:13 random >crw------- 1 Saltriver staff 0, 0 Apr 15 11:10 console ... >I think the output is same in both. Is there any way of mounting that device. You're going to need a driver of some sort that will make the GPS unit appear as a serial device. > I am very new to Mac. I am using RXTX 2.1 without javax.comm package. This problem is happening before RXTX can do anything at all. Unless there's a device in /dev, RXTX can't even begin to be involved. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From cowwoc at bbs.darktech.org Wed Apr 1 22:05:13 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Thu, 02 Apr 2009 00:05:13 -0400 Subject: [Rxtx] Windows 64-bit support? Message-ID: <49D43979.4050702@bbs.darktech.org> Hi, I'd like to run RXTX under the Windows 64-bit JVM. Are there plans to release an official 64-bit version anytime soon? Gili From bill7007 at gmail.com Thu Apr 2 16:01:17 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Thu, 2 Apr 2009 18:01:17 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel Message-ID: Hi, I have an rxtx serial application that used to work reliably until I had to move it to newer hardware and kernel. Now, the application sometimes hangs near first port use. When it does hang, it can be released by starting a second copy of the application which is locked out of the ports but does release the first process. Upgraded from rxtx-2.1-7-r2 to rxtx-2.2pre2 but still hangs. Tried to rebuild on the target machine and ran into the 'UTS_RELEASE' undeclared problem so holding on that approach. Recompiled OK on a 2.6.9-42.0.3.ELsmp system. Debug messages were turned on using: "./configure --enable-DEBUG" and modified RXTXPort.java with: "debug = true;" "z = new Zystem(Zystem.PRINT_MODE);" Below is capture of the application with debugging enabled. It show the application hang point, and the second application's printout at the release point. (pre3 is the locally modified version of pre2) Any suggestions on how to pin this down further? Thanks, +BillJ $ java -version java version "1.5.0_06" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05) Java HotSpot(TM) Client VM (build 1.5.0_06-b05, mixed mode, sharing) $ uname -a Linux qms4 2.6.18-92.1.6.el5 #1 SMP Wed Jun 25 13:49:24 EDT 2008 i686 i686 i386 GNU/Linux ***CAPTURE: [qms at qms4 ~]$ ./qms/ScriptFiles/startup.sh Thu Apr 02 13:35:45 EDT 2009:Setting Log File to:/home/qms/qms/QMS.log Thu Apr 02 13:35:45 EDT 2009:TSettings.HandleIni:ReUsing Ini file:/home/qms/qms/qms.properties WARNING: RXTX Version mismatch Jar version = RXTX-2.2pre2 native lib Version = RXTX-2.2pre3 fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB2 fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB1 fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB0 fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile RXTXPort {} RXTX WARNING: This library was compiled to run with OS release 2.4.20 and you are currently running OS release 2.6.18-92.1.6.el5. In some cases this can be a problem. Try recompiling RXTX if you notice strange behavior. If you just compiled RXTX make sure /usr/include/linux is a symbolic link to the include files that came with the kernel source and not an older copy. press enter to continue RXTXPort:RXTXPort(/dev/ttyUSB2) called fhs_lock: creating lockfile: 10127 open: locking worked for /dev/ttyUSB2 open: fd returned is 8 RXTXPort:MontitorThread:MonitorThread() RXTXPort:MontitorThread:run() has_line_status_register_acess: Port does not support TIOCSERGETLSR init_threads: get eis init_threads: set eis init_threads: stop RXTXPort:RXTXPort(/dev/ttyUSB2) returns with fd = 8 RXTXPort:setSerialPortParams(38400 8 1 0) called RXTXPort:setSerialPortParams(38400 8 1 0) returning RXTXPort:getInputStream() called and returning Thu Apr 02 13:36:02 EDT 2009:TSerial[22]:Using Port:/dev/ttyUSB2 RXTXPort:getOutputStream() called and returning Thu Apr 02 13:36:02 EDT 2009:TSerial[22].Transmit:TN Entering RXTXPort:SerialOutputStream:write(4) writeArray() Leaving RXTXPort:SerialOutputStream:write(4) RXTXPort:SerialOutputStream:flush() enter RXTXPort:SerialOutputStream:flush() leave Thu Apr 02 13:36:02 EDT 2009:TSerial[22].Transmit:RV Entering RXTXPort:SerialOutputStream:write(4) writeArray() Leaving RXTXPort:SerialOutputStream:write(4) RXTXPort:SerialOutputStream:flush() enter RXTXPort:SerialInputStream:read(8192 0 8192) called ***FIRST PROCESS HANGS HERE ***THEN PROCEEDS AFTER SECOND PROCESS STARTS RXTXPort:SerialOutputStream:flush() leave Thu Apr 02 13:41:29 EDT 2009:TSerial[22].Transmit:IH9 Entering RXTXPort:SerialOutputStream:write(5) writeArray() Leaving RXTXPort:SerialOutputStream:write(5) RXTXPort:SerialOutputStream:flush() enter RXTXPort:SerialOutputStream:flush() leave Thu Apr 02 13:41:29 EDT 2009:TSerial[22].Transmit:IL11 ***END CAPTURE ***CAPTURE SECOND PROCESS FAILS OPEN [qms at qms4 ~]$ ./qms/ScriptFiles/startup.sh Thu Apr 02 13:41:27 EDT 2009:Setting Log File to:/home/qms/qms/QMS.log Thu Apr 02 13:41:27 EDT 2009:TSettings.HandleIni:ReUsing Ini file:/home/qms/qms/qms.properties WARNING: RXTX Version mismatch Jar version = RXTX-2.2pre2 native lib Version = RXTX-2.2pre3 fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB2: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB1: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB0: File exists fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB2: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB1: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB0: File exists fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile Thu Apr 02 13:41:30 EDT 2009:TIOBoard: java.io.IOException: java.io.IOException: TSerial[22]: Open Failed ***END CAPTURE -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090402/c66f8d70/attachment-0014.html From netbeans at gatworks.com Thu Apr 2 17:15:04 2009 From: netbeans at gatworks.com (U. George) Date: Thu, 02 Apr 2009 19:15:04 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: Message-ID: <49D546F8.20807@gatworks.com> > "z = new Zystem(Zystem.PRINT_MODE);" > Below is capture of the application with debugging enabled. It show > the application hang point, and the second application's printout at the > release point. (pre3 is the locally modified version of pre2) > Any suggestions on how to pin this down further? > Thanks, > +BillJ When perceived runability is hung, try a ^\ ( control \) on console. This gets the JVM to dump the stacks of all the java threads. If you know the thread that is stuck, then u can see what java statement its stuck at. From tjarvi at qbang.org Thu Apr 2 19:25:17 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 2 Apr 2009 19:25:17 -0600 (MDT) Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: <49D546F8.20807@gatworks.com> References: <49D546F8.20807@gatworks.com> Message-ID: On Thu, 2 Apr 2009, U. George wrote: >> "z = new Zystem(Zystem.PRINT_MODE);" >> Below is capture of the application with debugging enabled. It show >> the application hang point, and the second application's printout at the >> release point. (pre3 is the locally modified version of pre2) >> Any suggestions on how to pin this down further? >> Thanks, >> +BillJ > > When perceived runability is hung, try a ^\ ( control \) on console. > This gets the JVM to dump the stacks of all the java threads. > If you know the thread that is stuck, then u can see what java statement > its stuck at. I've also noticed some linux systems hanging with open/read/write and saw kacpid storms. I need to look at it more but did observe kacpid consuming a core and not returning to a normal state for a significant period of time. It was easy to observe from top sorted by CPU usage. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Apr 2 19:26:18 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 2 Apr 2009 19:26:18 -0600 (MDT) Subject: [Rxtx] Windows 64-bit support? In-Reply-To: <49D43979.4050702@bbs.darktech.org> References: <49D43979.4050702@bbs.darktech.org> Message-ID: On Thu, 2 Apr 2009, cowwoc wrote: > Hi, > > I'd like to run RXTX under the Windows 64-bit JVM. Are there plans > to release an official 64-bit version anytime soon? > It is in the prerelease and will be in the final release. I'm pushing it through as fast as I can in my free time. -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Thu Apr 2 22:57:34 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Fri, 03 Apr 2009 00:57:34 -0400 Subject: [Rxtx] Missing documentation In-Reply-To: References: <49D43979.4050702@bbs.darktech.org> Message-ID: <49D5973E.4050400@bbs.darktech.org> Hi, I noticed that RXTX 2.1 drops javax.comm support in favor of gnu.io. I have one major problem with this: the gui.io.* documentation is very poor. Many classes and methods have no Javadoc at all which makes them difficult to use. Please fix this for the final release. Thank you, Gili From alex.sas at freemail.hu Fri Apr 3 01:36:54 2009 From: alex.sas at freemail.hu (Sas Alex) Date: Fri, 3 Apr 2009 09:36:54 +0200 (CEST) Subject: [Rxtx] Serial port false reads Message-ID: Hi all, On Windows XP, using rxtx-2.1-7-r2 I have a program communicating on a serial line like the following (excerpt): { os.write(command); os.flush(); // Thread.sleep(period); // read response while(is.available() > 0) { is.read() } } If there is a sleep between the os.flush and the reading cycle the correct answer is received. Otherwise (sometimes) there are extra, erronous characters at the beginning of the answer, but the correct answer (according to the protocol) also arrives, afterwards. Is this a normal behaviour, one should wait before the read? If yes, is there a way to determine the minimum amount of time to wait for? Serial port params are: 9600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE. Thank you in advance, Alex ________________________________________________________ El?foglal?si akci? meghosszabb?tva! Korfui ?d?l?s m?r 56.910 Ft-t?l. http://www.budavartours.hu/gorogorszag/?utm_campaign=origo&utm_source=freemail_kimeno_090403&utm_medium=ct&utm_content=korfu_elofoglalasi_akcio#reg_Korfu -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090403/8f3650ea/attachment-0014.html From bill7007 at gmail.com Fri Apr 3 16:15:30 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Fri, 3 Apr 2009 18:15:30 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: <49D546F8.20807@gatworks.com> Message-ID: > When perceived runability is hung, try a ^\ ( control \) on console. >> This gets the JVM to dump the stacks of all the java threads. > > Good idea... A thread dump is below, it looks like only some system threads are in wait state which is probably normal. The "main" thread is stopped writing the first data out the serial port which should complete but its has stopped at: at gnu.io.RXTXPort.nativeDrain(Native Method) It show its state as runnable though. There is another thread, "SerialReader_22", that is waiting to read any data on the same port. I'll bring the app up under Netbeans debugger next. >> > I've also noticed some linux systems hanging with open/read/write and saw > kacpid storms. No CPU use going when it hangs, acts like a deadlock. THREAD DUMP AT HANG: Entering RXTXPort:SerialOutputStream:write(4) writeArray() Leaving RXTXPort:SerialOutputStream:write(4) RXTXPort:SerialOutputStream:flush() enter RXTXPort:SerialInputStream:read(8192 0 8192) called Full thread dump Java HotSpot(TM) Client VM (1.5.0_06-b05 mixed mode, sharing): "SerialReader_22" daemon prio=1 tid=0x087abf38 nid=0x3c8b runnable [0xb1a43000..0xb1a43f30] at gnu.io.RXTXPort.readArray(Native Method) at gnu.io.RXTXPort$SerialInputStream.read(RXTXPort.java:1454) - locked <0x88ca55b8> (a gnu.io.RXTXPort$SerialInputStream) at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:411) at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) - locked <0x88cab378> (a java.io.InputStreamReader) at java.io.InputStreamReader.read(InputStreamReader.java:167) at java.io.BufferedReader.fill(BufferedReader.java:136) at java.io.BufferedReader.readLine(BufferedReader.java:299) - locked <0x88cab378> (a java.io.InputStreamReader) at java.io.BufferedReader.readLine(BufferedReader.java:362) at qms.TSerialPort$SerialRead.run(TSerialPort.java:268) at java.lang.Thread.run(Thread.java:595) "Thread-1" prio=1 tid=0x08a43360 nid=0x3c8a runnable [0xb1ac4000..0xb1ac4db0] at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1641) "AWT-XAWT" daemon prio=1 tid=0x08acc848 nid=0x3c87 runnable [0xb1b45000..0xb1b45e30] at sun.awt.X11.XToolkit.waitForEvents(Native Method) at sun.awt.X11.XToolkit.run(XToolkit.java:463) at sun.awt.X11.XToolkit.run(XToolkit.java:438) at java.lang.Thread.run(Thread.java:595) "Java2D Disposer" daemon prio=1 tid=0x08ab9d30 nid=0x3c86 in Object.wait() [0xb1bc6000..0xb1bc70b0] at java.lang.Object.wait(Native Method) - waiting on <0x8917b110> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:116) - locked <0x8917b110> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:132) at sun.java2d.Disposer.run(Disposer.java:107) at java.lang.Thread.run(Thread.java:595) "Low Memory Detector" daemon prio=1 tid=0x087bea68 nid=0x3c84 runnable [0x00000000..0x00000000] "CompilerThread0" daemon prio=1 tid=0x087bd4c0 nid=0x3c83 waiting on condition [0x00000000..0xb23a7a18] "Signal Dispatcher" daemon prio=1 tid=0x087bc520 nid=0x3c82 runnable [0x00000000..0x00000000] "Finalizer" daemon prio=1 tid=0x087b5710 nid=0x3c81 in Object.wait() [0xb26a9000..0xb26a9f30] at java.lang.Object.wait(Native Method) - waiting on <0x8914a770> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:116) - locked <0x8914a770> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:132) at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159) "Reference Handler" daemon prio=1 tid=0x087b49c8 nid=0x3c80 in Object.wait() [0xb272a000..0xb272adb0] at java.lang.Object.wait(Native Method) - waiting on <0x8914a7f0> (a java.lang.ref.Reference$Lock) at java.lang.Object.wait(Object.java:474) at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116) - locked <0x8914a7f0> (a java.lang.ref.Reference$Lock) "main" prio=1 tid=0x08777b88 nid=0x3c7e runnable [0xbffa7000..0xbffa74f8] at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1248) at qms.TSerialPort.Transmit(TSerialPort.java:192) - locked <0x88c99a68> (a qms.TSerialPort) at qms.TIOBoard.GetIOBoardVersion(TIOBoard.java:168) at qms.TIOBoard.(TIOBoard.java:73) at qms.TQMS.(TQMS.java:47) at qms.MainForm.(MainForm.java:2076) at qms.MainForm.main(MainForm.java:2099) "VM Thread" prio=1 tid=0x087b1e20 nid=0x3c7f runnable "VM Periodic Task Thread" prio=1 tid=0x087bff50 nid=0x3c85 waiting on condition -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090403/20b7bca4/attachment-0013.html From Martin.Oberhuber at windriver.com Fri Apr 3 16:23:43 2009 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Sat, 4 Apr 2009 00:23:43 +0200 Subject: [Rxtx] Missing documentation In-Reply-To: <49D5973E.4050400@bbs.darktech.org> References: <49D43979.4050702@bbs.darktech.org> <49D5973E.4050400@bbs.darktech.org> Message-ID: <460801A4097E3D4CA04CC64EE648584809C8BD6F@ism-mail03.corp.ad.wrs.com> Hello Gili, The classes in the gnu.io namespace are designed to work exactly as their counterparts in the javax.comm namespace. Therefore, if you just take the javax.comm Javadocs that's what you want. Unfortunately I don't think we can just copy & paste the javax.comm Javadocs into RXTX due to license restrictions. I guess that's the main reason why RXTX is not (yet) Javadoc'd as extensively as it should be. Actually, writing Javadocs from scratch WITHOUT referencing the wording of the Sun Javadocs is not that easy. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of cowwoc > Sent: Freitag, 03. April 2009 06:58 > To: rxtx at qbang.org > Subject: [Rxtx] Missing documentation > > Hi, > > I noticed that RXTX 2.1 drops javax.comm support in favor > of gnu.io. > I have one major problem with this: the gui.io.* > documentation is very > poor. Many classes and methods have no Javadoc at all which > makes them > difficult to use. Please fix this for the final release. > > Thank you, > Gili > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Fri Apr 3 16:54:50 2009 From: netbeans at gatworks.com (U. George) Date: Fri, 03 Apr 2009 18:54:50 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: <49D546F8.20807@gatworks.com> Message-ID: <49D693BA.8060909@gatworks.com> I would have tried 2 or 3 "^\" . If things are stuck, then all will be at same 'java' instruction. If thread is moving, then one of the snapshots would be different. I *think* flushing/draining wont return until the kernel buffers to device have been accepted by device. Stuck/paused device? Bill Johnson wrote: > > > > > When perceived runability is hung, try a ^\ ( control \) on console. > This gets the JVM to dump the stacks of all the java threads. > > > Good idea... A thread dump is below, it looks like only some system > threads are in wait state which is prob From cowwoc at bbs.darktech.org Fri Apr 3 17:45:09 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Fri, 03 Apr 2009 19:45:09 -0400 Subject: [Rxtx] Missing documentation In-Reply-To: <460801A4097E3D4CA04CC64EE648584809C8BD6F@ism-mail03.corp.ad.wrs.com> References: <49D43979.4050702@bbs.darktech.org> <49D5973E.4050400@bbs.darktech.org> <460801A4097E3D4CA04CC64EE648584809C8BD6F@ism-mail03.corp.ad.wrs.com> Message-ID: <49D69F85.3030804@bbs.darktech.org> You could always send Sun a formal email and ask for permission to copy their Javadoc. I doubt they would give you problems. Gili Oberhuber, Martin wrote: > Hello Gili, > > The classes in the gnu.io namespace are designed to work exactly > as their counterparts in the javax.comm namespace. Therefore, > if you just take the javax.comm Javadocs that's what you want. > > Unfortunately I don't think we can just copy & paste the > javax.comm Javadocs into RXTX due to license restrictions. > > I guess that's the main reason why RXTX is not (yet) Javadoc'd > as extensively as it should be. Actually, writing Javadocs > from scratch WITHOUT referencing the wording of the Sun > Javadocs is not that easy. > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] >> On Behalf Of cowwoc >> Sent: Freitag, 03. April 2009 06:58 >> To: rxtx at qbang.org >> Subject: [Rxtx] Missing documentation >> >> Hi, >> >> I noticed that RXTX 2.1 drops javax.comm support in favor >> of gnu.io. >> I have one major problem with this: the gui.io.* >> documentation is very >> poor. Many classes and methods have no Javadoc at all which >> makes them >> difficult to use. Please fix this for the final release. >> >> Thank you, >> Gili >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> From cowwoc at bbs.darktech.org Sat Apr 4 15:13:38 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sat, 04 Apr 2009 17:13:38 -0400 Subject: [Rxtx] Java5 support Message-ID: <49D7CD82.1040904@bbs.darktech.org> Now that you dropped javax.comm support, how about improving the API by replacing Enumation by Iterator, int by enum, and using Generics? It would improve the usability of the API. Gili From cowwoc at bbs.darktech.org Sat Apr 4 16:12:13 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sat, 04 Apr 2009 18:12:13 -0400 Subject: [Rxtx] RXTX Version mismatch in 2.2pre2 Message-ID: <49D7DB3D.5040008@bbs.darktech.org> When using RXTX-2.2pre2 I always get the following message: WARNING: RXTX Version mismatch Jar version = RXTX-2.2pre1 native lib Version = RXTX-2.2pre2 I have double checked that I am using the correct Jar file. Is this a known bug in pre2? Gili From tjarvi at qbang.org Sat Apr 4 16:48:53 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Apr 2009 16:48:53 -0600 (MDT) Subject: [Rxtx] RXTX Version mismatch in 2.2pre2 In-Reply-To: <49D7DB3D.5040008@bbs.darktech.org> References: <49D7DB3D.5040008@bbs.darktech.org> Message-ID: > When using RXTX-2.2pre2 I always get the following message: > > WARNING: RXTX Version mismatch > Jar version = RXTX-2.2pre1 > native lib Version = RXTX-2.2pre2 > Yep. You should still be able to test it. -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Sat Apr 4 16:50:43 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sat, 04 Apr 2009 18:50:43 -0400 Subject: [Rxtx] RXTX Version mismatch in 2.2pre2 In-Reply-To: References: <49D7DB3D.5040008@bbs.darktech.org> Message-ID: <49D7E443.9070404@bbs.darktech.org> In other words this is a known bug that will be fixed in the final version? Gili Trent Jarvi wrote: > > >> When using RXTX-2.2pre2 I always get the following message: >> >> WARNING: RXTX Version mismatch >> Jar version = RXTX-2.2pre1 >> native lib Version = RXTX-2.2pre2 >> > > Yep. > > You should still be able to test it. > > -- > Trent Jarvi > tjarvi at qbang.org From cowwoc at bbs.darktech.org Sat Apr 4 16:57:34 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sat, 04 Apr 2009 18:57:34 -0400 Subject: [Rxtx] IOException: Underlying input stream returned zero bytes Message-ID: <49D7E5DE.2050405@bbs.darktech.org> Hi, There seems to be a bug in RXTX 2.2pre2's handling of InputStream timeouts. If you open a serial port without ever invoking enableReceiveTimeout() then invoking InputStream.read() will always return 0 bytes right away. If you wrap the InputStream and invoke BufferedReader.readline() you will get the following exception: java.io.IOException: Underlying input stream returned zero bytes at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:268) [na:1.6.0_14-ea] at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:306) [na:1.6.0_14-ea] at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:158) [na:1.6.0_14-ea] at java.io.InputStreamReader.read(InputStreamReader.java:167) [na:1.6.0_14-ea] at java.io.BufferedReader.fill(BufferedReader.java:136) [na:1.6.0_14-ea] at java.io.BufferedReader.readLine(BufferedReader.java:299) [na:1.6.0_14-ea] at java.io.BufferedReader.readLine(BufferedReader.java:362) [na:1.6.0_14-ea] [snip] If you enable a timeout, the exception will only occur after the timeout expires. In short, it looks like RXTX is using a default timeout of zero (I am expecting it to block forever). It looks like other people have run into this as well: http://forums.sun.com/thread.jspa?threadID=5165346&start=10&tstart=0 Please confirm whether this is a known bug. Thank you, Gili From tjarvi at qbang.org Sat Apr 4 17:27:19 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Apr 2009 17:27:19 -0600 (MDT) Subject: [Rxtx] IOException: Underlying input stream returned zero bytes In-Reply-To: <49D7E5DE.2050405@bbs.darktech.org> References: <49D7E5DE.2050405@bbs.darktech.org> Message-ID: On Sat, 4 Apr 2009, cowwoc wrote: > Hi, > > There seems to be a bug in RXTX 2.2pre2's handling of InputStream > timeouts. If you open a serial port without ever invoking > enableReceiveTimeout() then invoking InputStream.read() will always > return 0 bytes right away. If you wrap the InputStream and invoke > BufferedReader.readline() you will get the following exception: > > java.io.IOException: Underlying input stream returned zero bytes > at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:268) > [na:1.6.0_14-ea] > at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:306) > [na:1.6.0_14-ea] > at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:158) > [na:1.6.0_14-ea] > at java.io.InputStreamReader.read(InputStreamReader.java:167) > [na:1.6.0_14-ea] > at java.io.BufferedReader.fill(BufferedReader.java:136) > [na:1.6.0_14-ea] > at java.io.BufferedReader.readLine(BufferedReader.java:299) > [na:1.6.0_14-ea] > at java.io.BufferedReader.readLine(BufferedReader.java:362) > [na:1.6.0_14-ea] > [snip] > > If you enable a timeout, the exception will only occur after the > timeout expires. In short, it looks like RXTX is using a default timeout > of zero (I am expecting it to block forever). It looks like other people > have run into this as well: > http://forums.sun.com/thread.jspa?threadID=5165346&start=10&tstart=0 > > Please confirm whether this is a known bug. > Hi Gili I've known about it but was not sure if it was a bug or not. It looks like we can treat it as a bug if nio is throwing an exception. Timeout and Thresholds are well documented in javax.comm but I didn't recall seeing defaults. For that reason, I've encouraged people to set the threshold and timeout to what they expect. Another note about InputStream.read(void): I noticed that I don't use that function at all while looking at code coverage results. Keep your eye out for additional issues. -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Sat Apr 4 19:03:29 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sat, 04 Apr 2009 21:03:29 -0400 Subject: [Rxtx] IOException: Underlying input stream returned zero bytes In-Reply-To: References: <49D7E5DE.2050405@bbs.darktech.org> Message-ID: <49D80361.7020801@bbs.darktech.org> Trent Jarvi wrote: > For that reason, I've encouraged people to set the threshold and timeout > to what they expect. It doesn't help. There doesn't seem to be a way to disable the timeout, even if you invoke disableReceiveTimeout() explicitly. Let me know when you put in a fix and I will test it. Thanks, Gili From cowwoc at bbs.darktech.org Sat Apr 4 23:27:25 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 01:27:25 -0400 Subject: [Rxtx] Crash in termios.c:892 Message-ID: <49D8413D.7040105@bbs.darktech.org> I can reproduce a crash in RXTX 2.2 pre2 100% of the time using my application code, but I can't seem to bring it down to a minimal testcase. Here is what I see: - thread begins running - open com1 - close com1 - open com5 - leave com5 open - thread shuts down - repeat the same process in a new thread - crash occurs when trying to open com1. Crash disappears if I close() com5 in the previous thread. The output window contains the following: # # A fatal error has been detected by the Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x05475cf6, pid=6064, tid=5436 # # JRE version: 6.0_14-b04 # Java VM: Java HotSpot(TM) Client VM (14.0-b13 mixed mode, sharing windows-x86 ) # Problematic frame: # C [rxtxSerial.dll+0x5cf6] # # An error report file with more information is saved as: # C:\Users\Gili\Documents\foobar\source\hs_err_pid6064.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp Error 0x5 at ..\src\termios.c(892): Access is denied. # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # Please let me know if the crash dump is enough to track down this bug. Thank you, Gili -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: hs_err_pid6064.log Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20090405/7133a1ce/attachment-0010.pl From cowwoc at bbs.darktech.org Sun Apr 5 00:24:19 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 02:24:19 -0400 Subject: [Rxtx] SerialPort.getName() is wrong Message-ID: <49D84E93.7050606@bbs.darktech.org> Sorry for all these emails but I keep on running into more issues. Here is what I noticed: - CommPortIdentifier.getPortIdentifier("COM5") returns a CommPortIdentifier where getName() == "COM5" - If, however, you invoke CommPortIdentifier.open() you get back a SerialPort where SerialPort.getName() is "//./COM5" I am expecting the name to remain consistent. "//./COM5" looks like an implementation detail and (as far as I can tell) it can't be used as an argument for any API method so it is somewhat useless. If getName() were to return "COM5" I could at least use it to get back the original CommPortIdentifier or compare against "known names" such as "COMx" or "LPTx". What do you think? Gili From tjarvi at qbang.org Sun Apr 5 10:18:42 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Apr 2009 10:18:42 -0600 (MDT) Subject: [Rxtx] SerialPort.getName() is wrong In-Reply-To: <49D84E93.7050606@bbs.darktech.org> References: <49D84E93.7050606@bbs.darktech.org> Message-ID: On Sun, 5 Apr 2009, cowwoc wrote: > > Sorry for all these emails but I keep on running into more issues. > Here is what I noticed: > > - CommPortIdentifier.getPortIdentifier("COM5") returns a > CommPortIdentifier where getName() == "COM5" > - If, however, you invoke CommPortIdentifier.open() you get back a > SerialPort where SerialPort.getName() is "//./COM5" > > I am expecting the name to remain consistent. "//./COM5" looks like > an implementation detail and (as far as I can tell) it can't be used as > an argument for any API method so it is somewhat useless. If getName() > were to return "COM5" I could at least use it to get back the original > CommPortIdentifier or compare against "known names" such as "COMx" or > "LPTx". What do you think? > Sure. If it itches enough you should be able to fix this in RXTXCommDriver.java. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Apr 5 10:27:58 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Apr 2009 10:27:58 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D8413D.7040105@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> Message-ID: On Sun, 5 Apr 2009, cowwoc wrote: > > I can reproduce a crash in RXTX 2.2 pre2 100% of the time using my > application code, but I can't seem to bring it down to a minimal testcase. > Here is what I see: > > - thread begins running > - open com1 > - close com1 > - open com5 > - leave com5 open > - thread shuts down > - repeat the same process in a new thread > - crash occurs when trying to open com1. Crash disappears if I close() com5 > in the previous thread. > > The output window contains the following: > > # > # A fatal error has been detected by the Java Runtime Environment: > # > # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x05475cf6, pid=6064, > tid=5436 > # > # JRE version: 6.0_14-b04 > # Java VM: Java HotSpot(TM) Client VM (14.0-b13 mixed mode, sharing > windows-x86 ) > # Problematic frame: > # C [rxtxSerial.dll+0x5cf6] > # > # An error report file with more information is saved as: > # C:\Users\Gili\Documents\foobar\source\hs_err_pid6064.log > # > # If you would like to submit a bug report, please visit: > # http://java.sun.com/webapps/bugreport/crash.jsp > Error 0x5 at ..\src\termios.c(892): Access is denied. > > > # The crash happened outside the Java Virtual Machine in native code. > # See problematic frame for where to report the bug. > # > > Please let me know if the crash dump is enough to track down this bug. > Hi Gili, You are responsible for cleaning up the serial ports when using threads. That said, if the thread did shut down, finalize should have been called if you are not passing the object around. See RXTXPort.java. protected void finalize() { if (debug) z.reportln( "RXTXPort:finalize()"); if( fd > 0 ) { if (debug) z.reportln( "RXTXPort:calling close()"); close(); } z.finalize(); } The exception is interesting. This is on Vista? Usually it just gives an open error when another process has the port. -- Trent Jarvi tjarvi at mathworks.com From cowwoc at bbs.darktech.org Sun Apr 5 10:35:55 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 12:35:55 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: References: <49D8413D.7040105@bbs.darktech.org> Message-ID: <49D8DDEB.5010908@bbs.darktech.org> Trent Jarvi wrote: > You are responsible for cleaning up the serial ports when using threads. > That said, if the thread did shut down, finalize should have been called > if you are not passing the object around. See RXTXPort.java. > > protected void finalize() > { > if (debug) > z.reportln( "RXTXPort:finalize()"); > if( fd > 0 ) > { > if (debug) > z.reportln( "RXTXPort:calling close()"); > close(); > } > z.finalize(); > } Two points: 1) One should never rely on finalizers because they may never run. 2) RXTX shouldn't cause the entire JVM to crash if I misuse the API. The native code should recover more gracefully. > The exception is interesting. This is on Vista? Usually it just gives > an open error when another process has the port. Yes, this is on Vista 64-bit. I'd really like to see this bug fixed. Is this code compilable under Visual Studio? If so, I can debug the problem on my end and send you a patch. Thanks, Gili From cowwoc at bbs.darktech.org Sun Apr 5 10:36:20 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 12:36:20 -0400 Subject: [Rxtx] SerialPort.getName() is wrong In-Reply-To: References: <49D84E93.7050606@bbs.darktech.org> Message-ID: <49D8DE04.6030306@bbs.darktech.org> Trent Jarvi wrote: >> I am expecting the name to remain consistent. "//./COM5" looks like >> an implementation detail and (as far as I can tell) it can't be used as >> an argument for any API method so it is somewhat useless. If getName() >> were to return "COM5" I could at least use it to get back the original >> CommPortIdentifier or compare against "known names" such as "COMx" or >> "LPTx". What do you think? >> > > Sure. > > If it itches enough you should be able to fix this in RXTXCommDriver.java. I'm not sure I understand. Are you saying that if I submit a patch you will commit it? Gili From tjarvi at qbang.org Sun Apr 5 10:46:23 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Apr 2009 10:46:23 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D8DDEB.5010908@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> Message-ID: On Sun, 5 Apr 2009, cowwoc wrote: > Trent Jarvi wrote: >> You are responsible for cleaning up the serial ports when using threads. >> That said, if the thread did shut down, finalize should have been called if >> you are not passing the object around. See RXTXPort.java. >> >> protected void finalize() >> { >> if (debug) >> z.reportln( "RXTXPort:finalize()"); >> if( fd > 0 ) >> { >> if (debug) >> z.reportln( "RXTXPort:calling close()"); >> close(); >> } >> z.finalize(); >> } > > Two points: > > 1) One should never rely on finalizers because they may never run. > 2) RXTX shouldn't cause the entire JVM to crash if I misuse the API. The > native code should recover more gracefully. > >> The exception is interesting. This is on Vista? Usually it just gives an >> open error when another process has the port. > > Yes, this is on Vista 64-bit. I'd really like to see this bug fixed. > Is this code compilable under Visual Studio? If so, I can debug the problem > on my end and send you a patch. > It will compile with the msvc cl.exe and nmake. See Makefile.msvc in the top level directory. You will need to adjust the JAVA_HOME variable. Also use the MSVC command prompt for x86_64 so cl and nmake are on your path. All the best, -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Apr 5 10:49:10 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Apr 2009 10:49:10 -0600 (MDT) Subject: [Rxtx] SerialPort.getName() is wrong In-Reply-To: <49D8DE04.6030306@bbs.darktech.org> References: <49D84E93.7050606@bbs.darktech.org> <49D8DE04.6030306@bbs.darktech.org> Message-ID: On Sun, 5 Apr 2009, cowwoc wrote: > Trent Jarvi wrote: >>> I am expecting the name to remain consistent. "//./COM5" looks like >>> an implementation detail and (as far as I can tell) it can't be used as >>> an argument for any API method so it is somewhat useless. If getName() >>> were to return "COM5" I could at least use it to get back the original >>> CommPortIdentifier or compare against "known names" such as "COMx" or >>> "LPTx". What do you think? >>> >> >> Sure. >> >> If it itches enough you should be able to fix this in RXTXCommDriver.java. > > I'm not sure I understand. Are you saying that if I submit a patch > you will commit it? > Hi Gili, Post a patch here and if nobody complains, we will commit it and give you credit. Yep. Other issues like changing the API to use java5 that may break existing apps are likely to run into objections but bug fixes usually get fixed just as you mention. -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Sun Apr 5 10:55:07 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 12:55:07 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> Message-ID: <49D8E26B.2040705@bbs.darktech.org> Trent Jarvi wrote: > It will compile with the msvc cl.exe and nmake. See Makefile.msvc in > the top level directory. You will need to adjust the JAVA_HOME > variable. Also use the MSVC command prompt for x86_64 so cl and nmake > are on your path. This is very odd. The CVS version of the code does not contain this file. Do you keep the latest code somewhere else? Gili From cowwoc at bbs.darktech.org Sun Apr 5 11:01:58 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 13:01:58 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D8E26B.2040705@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> Message-ID: <49D8E406.10708@bbs.darktech.org> cowwoc wrote: > Trent Jarvi wrote: >> It will compile with the msvc cl.exe and nmake. See Makefile.msvc in >> the top level directory. You will need to adjust the JAVA_HOME >> variable. Also use the MSVC command prompt for x86_64 so cl and nmake >> are on your path. > > This is very odd. The CVS version of the code does not contain this > file. Do you keep the latest code somewhere else? Okay I figured it out. CVS head is out of date, the "commapi-0-0-1" revision contains the correct files. Gili From tjarvi at qbang.org Sun Apr 5 11:05:43 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Apr 2009 11:05:43 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D8E26B.2040705@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> Message-ID: CVS HEAD is currently the rxtx 2.0 code. A branch was created long ago for 'experimental' gnu.io work. It just happens that the branch is what everyone uses now. checkout -r commapi-0-0-1 rxtx-devel will get the branch On Sun, 5 Apr 2009, cowwoc wrote: > Trent Jarvi wrote: >> It will compile with the msvc cl.exe and nmake. See Makefile.msvc in the >> top level directory. You will need to adjust the JAVA_HOME variable. Also >> use the MSVC command prompt for x86_64 so cl and nmake are on your path. > > This is very odd. The CVS version of the code does not contain this > file. Do you keep the latest code somewhere else? > > Gili > From cowwoc at bbs.darktech.org Sun Apr 5 14:50:47 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 16:50:47 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> Message-ID: <49D919A7.1070806@bbs.darktech.org> Okay, I tracked down the crash. It's being caused by YACK() using a 80-character buffer. The error message is longer than 80 characters, so _snprintf_s() crashes to avoid a buffer overflow. Please apply the attached patch and add the zipped up Visual Studio project directory. It's not perfect yet but it's a good start. Gili Trent Jarvi wrote: > > CVS HEAD is currently the rxtx 2.0 code. A branch was created long > ago for 'experimental' gnu.io work. It just happens that the branch > is what everyone uses now. > > checkout -r commapi-0-0-1 rxtx-devel > > will get the branch > > On Sun, 5 Apr 2009, cowwoc wrote: > >> Trent Jarvi wrote: >>> It will compile with the msvc cl.exe and nmake. See Makefile.msvc >>> in the top level directory. You will need to adjust the JAVA_HOME >>> variable. Also use the MSVC command prompt for x86_64 so cl and >>> nmake are on your path. >> >> This is very odd. The CVS version of the code does not contain >> this file. Do you keep the latest code somewhere else? >> >> Gili >> -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx-devel.patch Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20090405/d9b82962/attachment-0009.pl -------------- next part -------------- A non-text attachment was scrubbed... Name: Win32.zip Type: application/octet-stream Size: 17764 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20090405/d9b82962/attachment-0011.obj From cowwoc at bbs.darktech.org Sun Apr 5 15:22:01 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 17:22:01 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D919A7.1070806@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> <49D919A7.1070806@bbs.darktech.org> Message-ID: <49D920F9.6080702@bbs.darktech.org> My mistake. The problem in YACK is real, but it isn't the real cause of the crash. The crash is caused by termios.c line 1099: index->prev->next = port; because in my case "index->prev==0". I think the bug is that the code assumes that index will contain a minimum of two entries if we're inserting a previously closed fd. In my case, it only contains one. I'm not sure why you have this code branch (as opposed to appending to the end of index). Please take a look. Thanks, Gili cowwoc wrote: > > Okay, I tracked down the crash. It's being caused by YACK() using a > 80-character buffer. The error message is longer than 80 characters, so > _snprintf_s() crashes to avoid a buffer overflow. > > Please apply the attached patch and add the zipped up Visual Studio > project directory. It's not perfect yet but it's a good start. > > Gili > > Trent Jarvi wrote: >> >> CVS HEAD is currently the rxtx 2.0 code. A branch was created long >> ago for 'experimental' gnu.io work. It just happens that the branch >> is what everyone uses now. >> >> checkout -r commapi-0-0-1 rxtx-devel >> >> will get the branch >> >> On Sun, 5 Apr 2009, cowwoc wrote: >> >>> Trent Jarvi wrote: >>>> It will compile with the msvc cl.exe and nmake. See Makefile.msvc >>>> in the top level directory. You will need to adjust the JAVA_HOME >>>> variable. Also use the MSVC command prompt for x86_64 so cl and >>>> nmake are on your path. >>> >>> This is very odd. The CVS version of the code does not contain >>> this file. Do you keep the latest code somewhere else? >>> >>> Gili >>> From tjarvi at qbang.org Sun Apr 5 16:13:27 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Apr 2009 16:13:27 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D920F9.6080702@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> <49D919A7.1070806@bbs.darktech.org> <49D920F9.6080702@bbs.darktech.org> Message-ID: Hi Gili, Are you using the cvs version? I thought we fixed the linked list issues. A solution was posted to the list. Let me look at work tomorrow to see what I have. On Sun, 5 Apr 2009, cowwoc wrote: > > My mistake. The problem in YACK is real, but it isn't the real cause > of the crash. The crash is caused by termios.c line 1099: > > index->prev->next = port; > > because in my case "index->prev==0". I think the bug is that the code > assumes that index will contain a minimum of two entries if we're inserting a > previously closed fd. In my case, it only contains one. > > I'm not sure why you have this code branch (as opposed to appending > to the end of index). Please take a look. > > Thanks, > Gili > > cowwoc wrote: >> >> Okay, I tracked down the crash. It's being caused by YACK() using a >> 80-character buffer. The error message is longer than 80 characters, so >> _snprintf_s() crashes to avoid a buffer overflow. >> >> Please apply the attached patch and add the zipped up Visual Studio >> project directory. It's not perfect yet but it's a good start. >> >> Gili >> >> Trent Jarvi wrote: >>> >>> CVS HEAD is currently the rxtx 2.0 code. A branch was created long ago >>> for 'experimental' gnu.io work. It just happens that the branch is what >>> everyone uses now. >>> >>> checkout -r commapi-0-0-1 rxtx-devel >>> >>> will get the branch >>> >>> On Sun, 5 Apr 2009, cowwoc wrote: >>> >>>> Trent Jarvi wrote: >>>>> It will compile with the msvc cl.exe and nmake. See Makefile.msvc in >>>>> the top level directory. You will need to adjust the JAVA_HOME >>>>> variable. Also use the MSVC command prompt for x86_64 so cl and nmake >>>>> are on your path. >>>> >>>> This is very odd. The CVS version of the code does not contain this >>>> file. Do you keep the latest code somewhere else? >>>> >>>> Gili >>>> > From ilkka at myller.com Sun Apr 5 23:58:08 2009 From: ilkka at myller.com (Ilkka Myller) Date: Mon, 6 Apr 2009 08:58:08 +0300 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> <49D919A7.1070806@bbs.darktech.org> <49D920F9.6080702@bbs.darktech.org> Message-ID: <19779C97-E0C7-4E3D-B715-F84F50F00CE6@myller.com> Hi all, I've already submitted the patch to fix this issue in february: http://mailman.qbang.org/pipermail/rxtx/2009-February/3989441.html The patch fixes the mentioned doubly linked list handling in termios.c -- I Trent Jarvi kirjoitti 6.4.2009 kello 1.13: > > Hi Gili, > > Are you using the cvs version? I thought we fixed the linked list > issues. > A solution was posted to the list. Let me look at work tomorrow to > see > what I have. > > > > On Sun, 5 Apr 2009, cowwoc wrote: > >> >> My mistake. The problem in YACK is real, but it isn't the real cause >> of the crash. The crash is caused by termios.c line 1099: >> >> index->prev->next = port; >> >> because in my case "index->prev==0". I think the bug is that the >> code >> assumes that index will contain a minimum of two entries if we're >> inserting a >> previously closed fd. In my case, it only contains one. >> >> I'm not sure why you have this code branch (as opposed to appending >> to the end of index). Please take a look. >> >> Thanks, >> Gili >> >> cowwoc wrote: >>> >>> Okay, I tracked down the crash. It's being caused by YACK() >>> using a >>> 80-character buffer. The error message is longer than 80 >>> characters, so >>> _snprintf_s() crashes to avoid a buffer overflow. >>> >>> Please apply the attached patch and add the zipped up Visual >>> Studio >>> project directory. It's not perfect yet but it's a good start. >>> >>> Gili >>> >>> Trent Jarvi wrote: >>>> >>>> CVS HEAD is currently the rxtx 2.0 code. A branch was created >>>> long ago >>>> for 'experimental' gnu.io work. It just happens that the branch >>>> is what >>>> everyone uses now. >>>> >>>> checkout -r commapi-0-0-1 rxtx-devel >>>> >>>> will get the branch >>>> >>>> On Sun, 5 Apr 2009, cowwoc wrote: >>>> >>>>> Trent Jarvi wrote: >>>>>> It will compile with the msvc cl.exe and nmake. See >>>>>> Makefile.msvc in >>>>>> the top level directory. You will need to adjust the JAVA_HOME >>>>>> variable. Also use the MSVC command prompt for x86_64 so cl and >>>>>> nmake >>>>>> are on your path. >>>>> >>>>> This is very odd. The CVS version of the code does not >>>>> contain this >>>>> file. Do you keep the latest code somewhere else? >>>>> >>>>> Gili >>>>> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Steffen.DETTMER at ingenico.com Mon Apr 6 02:53:47 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 6 Apr 2009 10:53:47 +0200 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D919A7.1070806@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> <49D919A7.1070806@bbs.darktech.org> Message-ID: <20090406085347.GM8289@elberon.bln.de.ingenico.com> Hi, just two minor details, first about the errno change, I though #include extern int errno; is correct (POSIX.1) - why this change? second about the log message, I think the maximum length could be limited and the return value of malloc must be checked for != NULL before using. Should it be _snprintf_s( message, 80, _TRUNCATE, "Error 0x%x at %s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); (I know that MS-CRT _snprintf does not guarantee to have a final EOS, but I think _snprintf_s with _TRUNCATE does so?). If it is known that truncation may happen maybe sizeof[message] could be increased; maybe using some %.20s could be used avoiding __FILE__ including big pathes to a message where all the message had been cut-off. To have it portable I think it could be: /* generally: */ #if defined(_MSC_VER) # define snprintf _snprintf #endif snprintf(message, sizeof(message), "Error 0x%x at %.20s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); message[sizeof(message)-1] = '\0'; /* needed for MS CRT snprintf */ (for length and size parameter I think size_t could be an option, but on several platforms, including MS-CRT and older glibc, there is no %z, unfortunately) oki, Steffen * cowwoc wrote on Sun, Apr 05, 2009 at 16:50 -0400: > > Okay, I tracked down the crash. It's being caused by YACK() using a > 80-character buffer. The error message is longer than 80 characters, so > _snprintf_s() crashes to avoid a buffer overflow. > > Please apply the attached patch and add the zipped up Visual Studio > project directory. It's not perfect yet but it's a good start. > > Gili > > Trent Jarvi wrote: > > > >CVS HEAD is currently the rxtx 2.0 code. A branch was created long > >ago for 'experimental' gnu.io work. It just happens that the branch > >is what everyone uses now. > > > >checkout -r commapi-0-0-1 rxtx-devel > > > >will get the branch > > > >On Sun, 5 Apr 2009, cowwoc wrote: > > > >>Trent Jarvi wrote: > >>>It will compile with the msvc cl.exe and nmake. See Makefile.msvc > >>>in the top level directory. You will need to adjust the JAVA_HOME > >>>variable. Also use the MSVC command prompt for x86_64 so cl and > >>>nmake are on your path. > >> > >> This is very odd. The CVS version of the code does not contain > >>this file. Do you keep the latest code somewhere else? > >> > >>Gili > >> > Index: ParallelImp.c > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/ParallelImp.c,v > retrieving revision 1.15.2.36 > diff -u -r1.15.2.36 ParallelImp.c > --- ParallelImp.c 11 Feb 2009 01:04:19 -0000 1.15.2.36 > +++ ParallelImp.c 5 Apr 2009 17:55:23 -0000 > @@ -119,7 +119,7 @@ > # include > #endif > > -extern int errno; > +_CRTIMP extern int * __cdecl _errno(void); > > #include "ParallelImp.h" > > @@ -181,8 +181,6 @@ > > #if defined (WIN32) > > -#define CTL_CODE( DeviceType, Function, Method, Access ) (((DeviceType) << 16) | ((Access) << 14) | ((Function) << 2) | (Method)) > - > #define FILE_DEVICE_PARALLEL_PORT 0x00000016 > #define METHOD_BUFFERED 0 > #define FILE_ANY_ACCESS 0 > @@ -253,7 +251,6 @@ > jobject jobj) > { > int fd = get_java_var( env, jobj,"fd","I" ); > - int status; > #if defined (__linux__) > ioctl(fd, LPGETSTATUS, &status); > #elif defined (WIN32) > Index: SerialImp.c > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v > retrieving revision 1.46.2.203 > diff -u -r1.46.2.203 SerialImp.c > --- SerialImp.c 19 Mar 2009 03:27:48 -0000 1.46.2.203 > +++ SerialImp.c 5 Apr 2009 17:49:48 -0000 > @@ -147,7 +147,7 @@ > #include > #endif /* LIBLOCKDEV */ > > -extern int errno; > +_CRTIMP extern int * __cdecl _errno(void); > > #include "SerialImp.h" > > Index: termios.c > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/termios.c,v > retrieving revision 1.9.2.62 > diff -u -r1.9.2.62 termios.c > --- termios.c 13 Jan 2009 03:08:55 -0000 1.9.2.62 > +++ termios.c 5 Apr 2009 17:54:09 -0000 > @@ -88,7 +88,7 @@ > #define SIGIO 0 > > int my_errno; > -extern int errno; > +_CRTIMP extern int * __cdecl _errno(void); > struct termios_list > { > char filename[80]; > @@ -1350,7 +1350,7 @@ > In that case use EAGAIN. See SerialImp.c:testRead() > ----------------------------------------------------------*/ > > -int serial_read( int fd, void *vb, int size ) > +int serial_read( int fd, void *vb, unsigned int size ) > { > long start, now; > unsigned long nBytes = 0, total = 0, error; > Index: win32termios.h > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/win32termios.h,v > retrieving revision 1.5.2.34 > diff -u -r1.5.2.34 win32termios.h > --- win32termios.h 5 Feb 2009 01:25:05 -0000 1.5.2.34 > +++ win32termios.h 5 Apr 2009 20:29:30 -0000 > @@ -60,6 +60,7 @@ > #include > #include > #include > +#include > #ifdef TRACE > #define ENTER(x) report("entering "x" \n"); > #define LEAVE(x) report("leaving "x" \n"); > @@ -70,8 +71,9 @@ > #if defined(_MSC_VER) > #define YACK() \ > { \ > - char *allocTextBuf, message[80]; \ > - unsigned long nChars; \ > + char *allocTextBuf, *message; \ > + const unsigned short longestNumber = 20; \ > + unsigned long nChars, len; \ > unsigned int errorCode = GetLastError(); \ > nChars = FormatMessage ( \ > FORMAT_MESSAGE_ALLOCATE_BUFFER | \ > @@ -82,8 +84,12 @@ > (LPSTR)&allocTextBuf, \ > 16, \ > NULL ); \ > - _snprintf_s( message, 80, 80, "Error 0x%x at %s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); \ > + len = strlen("Error 0x") + longestNumber + strlen(" at ") + strlen(__FILE__) + longestNumber + \ > + strlen(": ") + ((nChars+1) * sizeof(TCHAR)) + 1; \ > + message = malloc(len); \ > + _snprintf_s( message, len, len - 1, "Error 0x%x at %s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); \ > report_error( message ); \ > + free(message); \ > LocalFree(allocTextBuf); \ > Sleep(1); \ > } > @@ -173,7 +179,7 @@ > int serial_test( char * ); > int serial_open(const char *File, int flags, ... ); > int serial_close(int fd); > -int serial_read(int fd, void *b, int size); > +int serial_read(int fd, void *b, unsigned int size); > int serial_write(int fd, char *Str, int length); > /* > * lcc winsock.h conflicts > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx End of message. ------------------------------------------------------------------->8======= About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From bill7007 at gmail.com Mon Apr 6 16:34:50 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Mon, 6 Apr 2009 18:34:50 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: <49D693BA.8060909@gatworks.com> References: <49D546F8.20807@gatworks.com> <49D693BA.8060909@gatworks.com> Message-ID: Once it hung, three stack dumps minutes apart were exactly the same. I have a noticed that when it hangs, the read appears after flush() enter and before flush leave() that doesn't happen like: RXTXPort:SerialOutputStream:flush() enter RXTXPort:SerialInputStream:read(8192 0 8192) called When it works, flush() enter and leave happen together. It may just be because flush() hangs and read is the only other thread waiting to run at that point. I don't know much about the RXTX design and kernel interaction, just digging through the code some. Is there a design description somewhere? Am hung up on target system compile since UTS_RELEASE seems no longer defined for 2.6.18 up kernels and have not figured a good patch yet. But, that is another issue. Thanks for the good help. On Fri, Apr 3, 2009 at 6:54 PM, U. George wrote: > I would have tried 2 or 3 "^\" . If things are stuck, then all will be at > same 'java' instruction. If thread is moving, then one of the snapshots > would be different. > > I *think* flushing/draining wont return until the kernel buffers to device > have been accepted by device. Stuck/paused device? > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090406/c4b509d8/attachment-0010.html From tjarvi at qbang.org Mon Apr 6 17:45:38 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 6 Apr 2009 17:45:38 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <20090406085347.GM8289@elberon.bln.de.ingenico.com> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> <49D919A7.1070806@bbs.darktech.org> <20090406085347.GM8289@elberon.bln.de.ingenico.com> Message-ID: The error bits in the patch can probably just be dropped out. I don't see what they solve. Your snprintf define appears to work. The following is what I'd like to put in if noone objects. #if defined(_MSC_VER) # define snprintf _snprintf #endif #define YACK() \ { \ char *allocTextBuf, message[80]; \ unsigned long nChars; \ unsigned int errorCode = GetLastError(); \ nChars = FormatMessage ( \ FORMAT_MESSAGE_ALLOCATE_BUFFER | \ FORMAT_MESSAGE_FROM_SYSTEM, \ NULL, \ errorCode, \ MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT), \ (LPSTR)&allocTextBuf, \ 16, \ NULL ); \ snprintf( message, 80, "Error 0x%x at %s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); \ message[sizeof(message)-1] = '\0'; /* needed for MS CRT snprintf */ \ report_error( message ); \ LocalFree(allocTextBuf); \ Sleep(1); \ } On Mon, 6 Apr 2009, Steffen DETTMER wrote: > Hi, > > just two minor details, first about the errno change, I though > > #include > extern int errno; > > is correct (POSIX.1) - why this change? > > second about the log message, I think the maximum length could be > limited and the return value of malloc must be checked for != > NULL before using. > > Should it be > > _snprintf_s( message, 80, _TRUNCATE, "Error 0x%x at %s(%d): %s\n", > errorCode, __FILE__, __LINE__, allocTextBuf); > > (I know that MS-CRT _snprintf does not guarantee to have a final > EOS, but I think _snprintf_s with _TRUNCATE does so?). > > If it is known that truncation may happen maybe sizeof[message] > could be increased; maybe using some %.20s could be used avoiding > __FILE__ including big pathes to a message where all the message > had been cut-off. > > To have it portable I think it could be: > > /* generally: */ > #if defined(_MSC_VER) > # define snprintf _snprintf > #endif > > snprintf(message, sizeof(message), "Error 0x%x at %.20s(%d): %s\n", > errorCode, __FILE__, __LINE__, allocTextBuf); > message[sizeof(message)-1] = '\0'; /* needed for MS CRT snprintf */ > > (for length and size parameter I think size_t could be an option, > but on several platforms, including MS-CRT and older glibc, > there is no %z, unfortunately) > > oki, > > Steffen > > > * cowwoc wrote on Sun, Apr 05, 2009 at 16:50 -0400: >> >> Okay, I tracked down the crash. It's being caused by YACK() using a >> 80-character buffer. The error message is longer than 80 characters, so >> _snprintf_s() crashes to avoid a buffer overflow. >> >> Please apply the attached patch and add the zipped up Visual Studio >> project directory. It's not perfect yet but it's a good start. >> >> Gili >> >> Trent Jarvi wrote: >> > >> >CVS HEAD is currently the rxtx 2.0 code. A branch was created long >> >ago for 'experimental' gnu.io work. It just happens that the branch >> >is what everyone uses now. >> > >> >checkout -r commapi-0-0-1 rxtx-devel >> > >> >will get the branch >> > >> >On Sun, 5 Apr 2009, cowwoc wrote: >> > >> >>Trent Jarvi wrote: >> >>>It will compile with the msvc cl.exe and nmake. See Makefile.msvc >> >>>in the top level directory. You will need to adjust the JAVA_HOME >> >>>variable. Also use the MSVC command prompt for x86_64 so cl and >> >>>nmake are on your path. >> >> >> >> This is very odd. The CVS version of the code does not contain >> >>this file. Do you keep the latest code somewhere else? >> >> >> >>Gili >> >> > >> Index: ParallelImp.c >> =================================================================== >> RCS file: /usr/local/cvsroot/rxtx-devel/src/ParallelImp.c,v >> retrieving revision 1.15.2.36 >> diff -u -r1.15.2.36 ParallelImp.c >> --- ParallelImp.c 11 Feb 2009 01:04:19 -0000 1.15.2.36 >> +++ ParallelImp.c 5 Apr 2009 17:55:23 -0000 >> @@ -119,7 +119,7 @@ >> # include >> #endif >> >> -extern int errno; >> +_CRTIMP extern int * __cdecl _errno(void); >> >> #include "ParallelImp.h" >> >> @@ -181,8 +181,6 @@ >> >> #if defined (WIN32) >> >> -#define CTL_CODE( DeviceType, Function, Method, Access ) (((DeviceType) << 16) | ((Access) << 14) | ((Function) << 2) | (Method)) >> - >> #define FILE_DEVICE_PARALLEL_PORT 0x00000016 >> #define METHOD_BUFFERED 0 >> #define FILE_ANY_ACCESS 0 >> @@ -253,7 +251,6 @@ >> jobject jobj) >> { >> int fd = get_java_var( env, jobj,"fd","I" ); >> - int status; >> #if defined (__linux__) >> ioctl(fd, LPGETSTATUS, &status); >> #elif defined (WIN32) >> Index: SerialImp.c >> =================================================================== >> RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v >> retrieving revision 1.46.2.203 >> diff -u -r1.46.2.203 SerialImp.c >> --- SerialImp.c 19 Mar 2009 03:27:48 -0000 1.46.2.203 >> +++ SerialImp.c 5 Apr 2009 17:49:48 -0000 >> @@ -147,7 +147,7 @@ >> #include >> #endif /* LIBLOCKDEV */ >> >> -extern int errno; >> +_CRTIMP extern int * __cdecl _errno(void); >> >> #include "SerialImp.h" >> >> Index: termios.c >> =================================================================== >> RCS file: /usr/local/cvsroot/rxtx-devel/src/termios.c,v >> retrieving revision 1.9.2.62 >> diff -u -r1.9.2.62 termios.c >> --- termios.c 13 Jan 2009 03:08:55 -0000 1.9.2.62 >> +++ termios.c 5 Apr 2009 17:54:09 -0000 >> @@ -88,7 +88,7 @@ >> #define SIGIO 0 >> >> int my_errno; >> -extern int errno; >> +_CRTIMP extern int * __cdecl _errno(void); >> struct termios_list >> { >> char filename[80]; >> @@ -1350,7 +1350,7 @@ >> In that case use EAGAIN. See SerialImp.c:testRead() >> ----------------------------------------------------------*/ >> >> -int serial_read( int fd, void *vb, int size ) >> +int serial_read( int fd, void *vb, unsigned int size ) >> { >> long start, now; >> unsigned long nBytes = 0, total = 0, error; >> Index: win32termios.h >> =================================================================== >> RCS file: /usr/local/cvsroot/rxtx-devel/src/win32termios.h,v >> retrieving revision 1.5.2.34 >> diff -u -r1.5.2.34 win32termios.h >> --- win32termios.h 5 Feb 2009 01:25:05 -0000 1.5.2.34 >> +++ win32termios.h 5 Apr 2009 20:29:30 -0000 >> @@ -60,6 +60,7 @@ >> #include >> #include >> #include >> +#include >> #ifdef TRACE >> #define ENTER(x) report("entering "x" \n"); >> #define LEAVE(x) report("leaving "x" \n"); >> @@ -70,8 +71,9 @@ >> #if defined(_MSC_VER) >> #define YACK() \ >> { \ >> - char *allocTextBuf, message[80]; \ >> - unsigned long nChars; \ >> + char *allocTextBuf, *message; \ >> + const unsigned short longestNumber = 20; \ >> + unsigned long nChars, len; \ >> unsigned int errorCode = GetLastError(); \ >> nChars = FormatMessage ( \ >> FORMAT_MESSAGE_ALLOCATE_BUFFER | \ >> @@ -82,8 +84,12 @@ >> (LPSTR)&allocTextBuf, \ >> 16, \ >> NULL ); \ >> - _snprintf_s( message, 80, 80, "Error 0x%x at %s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); \ >> + len = strlen("Error 0x") + longestNumber + strlen(" at ") + strlen(__FILE__) + longestNumber + \ >> + strlen(": ") + ((nChars+1) * sizeof(TCHAR)) + 1; \ >> + message = malloc(len); \ >> + _snprintf_s( message, len, len - 1, "Error 0x%x at %s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); \ >> report_error( message ); \ >> + free(message); \ >> LocalFree(allocTextBuf); \ >> Sleep(1); \ >> } >> @@ -173,7 +179,7 @@ >> int serial_test( char * ); >> int serial_open(const char *File, int flags, ... ); >> int serial_close(int fd); >> -int serial_read(int fd, void *b, int size); >> +int serial_read(int fd, void *b, unsigned int size); >> int serial_write(int fd, char *Str, int length); >> /* >> * lcc winsock.h conflicts >> > > >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > > > > > > > > > > > > End of message. > ------------------------------------------------------------------->8======= > > > About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. > This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > P Please consider the environment before printing this e-mail > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Apr 6 18:11:28 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 6 Apr 2009 18:11:28 -0600 (MDT) Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: <49D546F8.20807@gatworks.com> <49D693BA.8060909@gatworks.com> Message-ID: UTS_RELEASE is defined in now. The check really should be removed from RXTX. It was a defensive check for wilder times when GNU glibc did not have defines the kernel headers had so rxtx would include the kernel headers instead. :/ If you don't have linux/version.h, it is generated when you configure the kernel. make oldconfig used to do the trick. It may make sense to work with the prerelease or CVS code. RXTX just assumes that flush, read and anything else the kernel exposes may be called at anytime from any thread. There isn't a design for the kernel interaction. There are higher level constraints put in Java to prevent some things happening at the same time with 'synchronized.' RXTXPort.java has all of those. When the port is opened, a native event thread is started which uses select to know if an event has happened. BSD like systems have a native thread that fires off on write which tries to flush() to determine when the output buffer is empty asynchronously. The rest is not marshaled in any fashion at the native level. T I think there is a lower level deadlock being triggered in flush as well. I don't think it should be possible if everything was right underneath us. You may want to examine the java code closer to make sure it isnt possible the lock is there. On Mon, 6 Apr 2009, Bill Johnson wrote: > Once it hung, three stack dumps minutes apart were exactly the same. > I have a noticed that when it hangs, the read appears after flush() enter and > before flush leave() that doesn't happen like: > RXTXPort:SerialOutputStream:flush() enter > RXTXPort:SerialInputStream:read(8192 0 8192) called > > When it works, flush() enter and leave happen together. It may just be because > flush() hangs and read is the only other thread waiting to run at that point. > I don't know much about the RXTX design and kernel interaction, just digging > through the code some. Is there a design description somewhere? > > Am hung up on target system compile since UTS_RELEASE seems no longer defined for > 2.6.18 up kernels and have not figured a good patch yet. But, that is another > issue. > > Thanks for the good help. > > > On Fri, Apr 3, 2009 at 6:54 PM, U. George wrote: > I would have tried 2 or 3 "^\" . If things are stuck, then all will be > at same 'java' instruction. If thread is moving, then one of the > snapshots would be different. > > I *think* flushing/draining wont return until the kernel buffers to > device have been accepted by device. Stuck/paused device? > > > > > From tjarvi at qbang.org Mon Apr 6 18:28:50 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 6 Apr 2009 18:28:50 -0600 (MDT) Subject: [Rxtx] CVS updates. Pre3 is comming. Message-ID: I need to go through the bugzilla reports prior to the pre3 release. I think this should be close if you want to check it out from CVS. added: YACK() debug overflow fix for windows Steffen DETTMER (and many others) multiport fix for windows. Ilkka Myller http://mailman.qbang.org/pipermail/rxtx/2009-February/3989441.html I think this code is current. If I missed something, yell. CVS Info: export/setenv CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login # passwd mousy cvs checkout -r commapi-0-0-1 rxtx-devel -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Apr 6 22:32:07 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 6 Apr 2009 22:32:07 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D919A7.1070806@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> <49D919A7.1070806@bbs.darktech.org> Message-ID: Ah. I'll put this in CVS tomorrow. I did sync up the code with my work sandbox today. I just forgot to pull and add this. On Sun, 5 Apr 2009, cowwoc wrote: > > Okay, I tracked down the crash. It's being caused by YACK() using a > 80-character buffer. The error message is longer than 80 characters, so > _snprintf_s() crashes to avoid a buffer overflow. > > Please apply the attached patch and add the zipped up Visual Studio > project directory. It's not perfect yet but it's a good start. > > Gili > > Trent Jarvi wrote: >> >> CVS HEAD is currently the rxtx 2.0 code. A branch was created long ago for >> 'experimental' gnu.io work. It just happens that the branch is what >> everyone uses now. >> >> checkout -r commapi-0-0-1 rxtx-devel >> >> will get the branch >> >> On Sun, 5 Apr 2009, cowwoc wrote: >> >>> Trent Jarvi wrote: >>>> It will compile with the msvc cl.exe and nmake. See Makefile.msvc in the >>>> top level directory. You will need to adjust the JAVA_HOME variable. >>>> Also use the MSVC command prompt for x86_64 so cl and nmake are on your >>>> path. >>> >>> This is very odd. The CVS version of the code does not contain this >>> file. Do you keep the latest code somewhere else? >>> >>> Gili >>> > From cowwoc at bbs.darktech.org Tue Apr 7 06:07:46 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Tue, 07 Apr 2009 08:07:46 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: References: Message-ID: <49DB4212.40807@bbs.darktech.org> > just two minor details, first about the errno change, I though > > #include > extern int errno; > > is correct (POSIX.1) - why this change? If you compile this under Visual Studio 2008 you will get warnings that the errno type being imported is different from the type being exported. The definition I pasted is the one being exported. Perhaps we should use #ifdef WIN32 for this? Gili From bill7007 at gmail.com Tue Apr 7 17:58:54 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Tue, 7 Apr 2009 19:58:54 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: <49D546F8.20807@gatworks.com> <49D693BA.8060909@gatworks.com> Message-ID: I have traced the hang down to a call to tcdrain(fd) in SerialImp.c:drain() running and rebuilt under Netbeans on the target machine with debug messages on. That puts it into the system code, so I'm not sure how to proceed. I guess I could debug into the kernel source but I've not done that. I saw some discussion about an IOCTL that sets/adjusts a timeout on tcdrain() but that may have been for BSD. Maybe there is some new setup requirement or bug introduced with this 2.6.18 kernel or a hardware difference. Below is a message listing with some of the repeated parts removed. Maybe you can see something noteworthy? JNI_OnLoad called. WARNING: RXTX Version mismatch Jar version = RXTX-2.2pre2 native lib Version = RXTX-2.2pre3 entering RXTXCommDriver:getDeviceDirectory entering RXTXPort:testRead fhs_lock: creating lockfile: 29704 fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXPort:testRead RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB2 fhs_lock: creating lockfile: 29704 fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXPort:testRead RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB1 fhs_lock: creating lockfile: 29704 fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXPort:testRead RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB0 fhs_lock: creating lockfile: 29704 fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXPort:testRead fhs_lock: creating lockfile: 29704 ... REPEATS fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXPort:testRead fhs_lock: creating lockfile: 29704 fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXCommDriver:getDeviceDirectory entering RXTXPort:testRead fhs_lock: creating lockfile: 29704 ...REPEATS fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXPort:testRead fhs_lock: creating lockfile: 29704 fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXPort:Initialize RXTX WARNING: This library was compiled to run with OS release 2.6.18 and you are currently running OS release 2.6.18-92.1.6.el5. In some cases this can be a problem. Try recompiling RXTX if you notice strange behavior. If you just compiled RXTX make sure /usr/include/linux is a symbolic link to the include files that came with the kernel source and not an older copy. press enter to continue leaving RXTXPort:Initialize entering RXTXPort:open fhs_lock: creating lockfile: 29704 open: locking worked for /dev/ttyUSB2 open: fd returned is 9 leaving RXTXPort:open entering eventLoop has_line_status_register_acess: Port does not support TIOCSERGETLSR driver_has_tiocgicount: Port does not support TIOCGICOUNT events init_threads: get eis init_threads: set eis init_threads: stop leaving RXTXPort:translate_speed entering RXTXPort:nativeSetSerialPortParams entering translate_date_bits entering translate_stop_bits leaving RXTXPort:translate_stop_bits entering translate_parity leaving translate_parity entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 ...REPEATS entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 leaving RXTXPort:nativeSetSerialPortParams entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 ...REPEATS entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 entering writeArray entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 writeArray() leaving RXTXPort:writeArray entering SerialImp.c:drain() nativeDrain: trying tcdrain RXTXPort:drain() returns: 0 leaving RXTXPort:drain() entering writeArray writeArray() leaving RXTXPort:writeArray entering SerialImp.c:drain() nativeDrain: trying tcdrain entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 Tue Apr 07 18:51:49 EDT 2009:TSerial[22]:Using Port:/dev/ttyUSB2 Tue Apr 07 18:51:49 EDT 2009:TSerial[22].Transmit:TN Tue Apr 07 18:51:49 EDT 2009:TSerial[22].Transmit:RV entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 ...REPEATS FOREVER? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090407/f26e5752/attachment-0009.html From tjarvi at qbang.org Tue Apr 7 18:31:23 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 7 Apr 2009 18:31:23 -0600 (MDT) Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: <49D546F8.20807@gatworks.com> <49D693BA.8060909@gatworks.com> Message-ID: On Tue, 7 Apr 2009, Bill Johnson wrote: > I have traced the hang down to a call to tcdrain(fd) in SerialImp.c:drain() > running and rebuilt under Netbeans on the target machine with debug messages > on. That puts it into the system code, so I'm not sure how to proceed. I > guess I could debug into the kernel source but I've not done that. I saw > some discussion about an IOCTL that sets/adjusts a timeout on tcdrain() but > that may have been for BSD. Maybe there is some new setup requirement or bug > introduced with this 2.6.18 kernel or a hardware difference. > Below is a message listing with some of the repeated parts removed. Maybe > you can see something noteworthy? > > JNI_OnLoad called. > WARNING:? RXTX Version mismatch > ??????? Jar version = RXTX-2.2pre2 > ??????? native lib Version = RXTX-2.2pre3 > entering RXTXCommDriver:getDeviceDirectory > entering RXTXPort:testRead > fhs_lock: creating lockfile:????? 29704 > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXPort:testRead > RXTX Warning:? Removing stale lock file. /var/lock/LCK..ttyUSB2 > fhs_lock: creating lockfile:????? 29704 > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXPort:testRead > RXTX Warning:? Removing stale lock file. /var/lock/LCK..ttyUSB1 > fhs_lock: creating lockfile:????? 29704 > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXPort:testRead > RXTX Warning:? Removing stale lock file. /var/lock/LCK..ttyUSB0 > fhs_lock: creating lockfile:????? 29704 > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXPort:testRead > fhs_lock: creating lockfile:????? 29704 > > ... REPEATS > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXPort:testRead > fhs_lock: creating lockfile:????? 29704 > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXCommDriver:getDeviceDirectory > entering RXTXPort:testRead > fhs_lock: creating lockfile:????? 29704 > > ...REPEATS > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXPort:testRead > fhs_lock: creating lockfile:????? 29704 > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXPort:Initialize > > > > RXTX WARNING:? This library was compiled to run with OS release 2.6.18 and > you are currently running OS release 2.6.18-92.1.6.el5.? In some cases this > can be a problem.? Try recompiling RXTX if you notice strange behavior.? If > you just compiled RXTX make sure /usr/include/linux is a symbolic link to > the include files that came with the kernel source and not an older copy. > > > press enter to continue > > leaving RXTXPort:Initialize > entering RXTXPort:open > fhs_lock: creating lockfile:????? 29704 > > open: locking worked for /dev/ttyUSB2 > open: fd returned is 9 > leaving RXTXPort:open > entering eventLoop > ? > has_line_status_register_acess: Port does not support TIOCSERGETLSR > ?driver_has_tiocgicount:? Port does not support TIOCGICOUNT events > init_threads: get eis > init_threads: set eis > init_threads:? stop > leaving RXTXPort:translate_speed > entering RXTXPort:nativeSetSerialPortParams > entering translate_date_bits > entering translate_stop_bits > leaving RXTXPort:translate_stop_bits > entering translate_parity > leaving translate_parity > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > ...REPEATS > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > leaving RXTXPort:nativeSetSerialPortParams > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > ...REPEATS > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > entering writeArray > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > writeArray() > leaving RXTXPort:writeArray > entering SerialImp.c:drain() > nativeDrain: trying tcdrain > RXTXPort:drain() returns: 0 > leaving RXTXPort:drain() > entering writeArray > writeArray() > leaving RXTXPort:writeArray > entering SerialImp.c:drain() > nativeDrain: trying tcdrain > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > Tue Apr 07 18:51:49 EDT 2009:TSerial[22]:Using Port:/dev/ttyUSB2 > Tue Apr 07 18:51:49 EDT 2009:TSerial[22].Transmit:TN > > Tue Apr 07 18:51:49 EDT 2009:TSerial[22].Transmit:RV > > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > ...REPEATS FOREVER? > > > Hi Bill ugh. The tiocmget... is the eventLoop checking for events. It sits with select() but has a timeout value to keep it spinning at a trivial rate. tcdrain() is the suspect. I don't see anything in the code that looks like a problem. If flow control is not enabled, I don't see a reason for it not to return. Given that this is USB, perhaps a message from the device got lost. Onboard UARTs would have a status register change when output buffer is empty. USB needs to communicate the event as an HID device which may be the source of the error. Dropping back to onboard UARTs eliminates that portion of the mix. What vendor/chipset is the USB dongle? I understand code has been pushed upon the linux serial devices for new for things like acpi. There very well could be a bug introduced. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Apr 7 18:38:22 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 7 Apr 2009 18:38:22 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49DB4212.40807@bbs.darktech.org> References: <49DB4212.40807@bbs.darktech.org> Message-ID: On Tue, 7 Apr 2009, cowwoc wrote: >> just two minor details, first about the errno change, I though >> >> #include >> extern int errno; >> >> is correct (POSIX.1) - why this change? > > If you compile this under Visual Studio 2008 you will get warnings that > the errno type being imported is different from the type being exported. > The definition I pasted is the one being exported. Perhaps we should use > #ifdef WIN32 for this? > Hi Gili, Perhaps a workaround for _MSVC is in order. GNU compilers for windows won't complain. If it's a question of MSVC or POSIX being right, the library favors the standard as a stated goal. I'm not sure what MSVC is using errno for but it should not be using it except with POSIX extensions. Perhaps #undef is enough to get rid of the warning and (maybe) has no ill consequences. Newer windows have POSIX extensions that may show how Microsoft solved the problem. It can probably fester. -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Tue Apr 7 19:54:06 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Tue, 07 Apr 2009 21:54:06 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: References: <49DB4212.40807@bbs.darktech.org> Message-ID: <49DC03BE.5010203@bbs.darktech.org> Trent Jarvi wrote: > I'm not sure what MSVC is using errno for but it should not be using it > except with POSIX extensions. Perhaps #undef is enough to get rid of > the warning and (maybe) has no ill consequences. Newer windows have > POSIX extensions that may show how Microsoft solved the problem. > > It can probably fester. What does "newer windows" refer to in this case? I was compiling using Visual Studio 2008 sp1 under Windows Vista. Both are cutting edge technologies as far as official releases go. I think you're best suited to judge whether this warning is a big deal or not so I think you should see it for yourself. Please try firing up Visual Studio 2008 (express?) against the project I sent you. Gili From Steffen.DETTMER at ingenico.com Wed Apr 8 05:50:42 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 8 Apr 2009 13:50:42 +0200 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49DC03BE.5010203@bbs.darktech.org> References: <49DB4212.40807@bbs.darktech.org> <49DC03BE.5010203@bbs.darktech.org> Message-ID: <20090408115042.GC5090@elberon.bln.de.ingenico.com> * cowwoc wrote on Tue, Apr 07, 2009 at 21:54 -0400: > Trent Jarvi wrote: > > I'm not sure what MSVC is using errno for but it should not be using it > > except with POSIX extensions. Perhaps #undef is enough to get rid of > > the warning and (maybe) has no ill consequences. Newer windows have > > POSIX extensions that may show how Microsoft solved the problem. I think here best is simply to omit this old^Wclassic `extern int errno;' line completely. I think standards just say something like `implementations may support the declaration extern int errno;'. About POSIX extensions I think in general it should be considered that althrough many things are available, even with MS Visual C++, the Microsoft tools lead developers to write non-portable code (and personally I think this is intentional). For example, they call the official ISO-C function `strerror' deprecated (!) and twaddle about some security enhancements (without even beeing specific). Someone could, because of this, lead to use the MS specific, unportable `strerror_s' instead. Even better, at _strerror_s they tell, for `ANSI compatiblity someone should use strerror_s'. Of course a program using [_]strerror_s won't be ANSI-C compliant. Do they mean strerror_r? _strerror_s has the same parameters - but of course in different order - to make porting a pain... SCNR. > What does "newer windows" refer to in this case? I was compiling using > Visual Studio 2008 sp1 under Windows Vista. Both are cutting edge > technologies as far as official releases go. `cutting edge technologies' yeah post-standard, portability-cutting technologies smoothing the way to MS world domination; own post-ANSI-C programming languages help (maybe to increase the share holder value)... SCNR. > I think you're best suited to judge whether this warning is a big deal > or not so I think you should see it for yourself. Please try firing up > Visual Studio 2008 (express?) against the project I sent you. yeah, getting the CL.EXE of 2008 running in a normal command line environment (without its special `C++ Shell') is a bit tricky - but possible. ;) oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From tjarvi at qbang.org Wed Apr 8 14:29:54 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 8 Apr 2009 14:29:54 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49DC03BE.5010203@bbs.darktech.org> References: <49DB4212.40807@bbs.darktech.org> <49DC03BE.5010203@bbs.darktech.org> Message-ID: The support has been around for a long time to. I don't know the details but the support appears to be tied to the OS. http://en.wikipedia.org/wiki/POSIX#POSIX_for_Windows On Tue, 7 Apr 2009, cowwoc wrote: > Trent Jarvi wrote: >> I'm not sure what MSVC is using errno for but it should not be using it >> except with POSIX extensions. Perhaps #undef is enough to get rid of the >> warning and (maybe) has no ill consequences. Newer windows have POSIX >> extensions that may show how Microsoft solved the problem. >> >> It can probably fester. > > What does "newer windows" refer to in this case? I was compiling > using Visual Studio 2008 sp1 under Windows Vista. Both are cutting edge > technologies as far as official releases go. > > I think you're best suited to judge whether this warning is a big > deal or not so I think you should see it for yourself. Please try firing up > Visual Studio 2008 (express?) against the project I sent you. > > Gili > From bill7007 at gmail.com Wed Apr 8 15:59:08 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Wed, 8 Apr 2009 17:59:08 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: <49D546F8.20807@gatworks.com> <49D693BA.8060909@gatworks.com> Message-ID: Hi Trent, I think I have hit on a work around but don't know why it works. The USB serial adapter is a "CableMAX" based on Prolific's PL2303. Backing out to the big picture, the application is old and has been very reliable until put on a new cpu and kernel. It only hangs sometimes say 25% and always at the same place, at tcdrain() on the flush() after the second write after startup. If it made it past this stage, all transmit and receive seemed reliable so it was like a startup timing issue. Since learning to debug kernel code is beyond my immediate priority, I took a shot at moving code around, adding delays, and such. I have found it good practice to do a flush after every write on streams like: outputStream.write(data.getBytes()); outputStream.flush(); If I remove the flush() after each write, the problem appears to go away! I don't think the flush is needed for a SerialOutputStream for this application anyway. Thanks for all the help, +BillJ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090408/35d96a9d/attachment-0008.html From bill7007 at gmail.com Thu Apr 9 09:20:11 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Thu, 9 Apr 2009 11:20:11 -0400 Subject: [Rxtx] Baud rate fixes in 2.2pre2 breaks 38400 on some Linux devices Message-ID: Hello, An application that worked at 38400 on a USB serial adapter (PL2303) using 2.1-7-r2 on Linux EL4 (and EL5) now fails using 2.2pre2. serialPort.setSerialPortParams(38400,SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); throws an unsupportedCommOperationException This problem matched a description of Bug 113and I posted a proposed patch there, but I don't understand the whole custom baud rate patch so it may need some thought. An older patch, [Rxtx] [Patch]: Baud Rate fixes try 1, testing encouraged., fixed some custom baud rates but apparently broke 38400 on some Linux device. Other baud rates seem to work OK. And, 38400 tested OK on local non-USB ports. My proposed patch probably breaks the custom baud rate patch since it was keyed on 38400 as a special case for Linux and my fix was to back out part of that patch, specifically: #if defined(TIOCGSERIAL) if ( cspeed == B38400 ) cspeed = 38400; #endif /* TIOCGSERIAL */ +BillJ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090409/5636af64/attachment-0007.html From cowwoc at bbs.darktech.org Fri Apr 10 08:38:49 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Fri, 10 Apr 2009 10:38:49 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: References: <49DB4212.40807@bbs.darktech.org> <49DC03BE.5010203@bbs.darktech.org> Message-ID: <49DF59F9.2050408@bbs.darktech.org> Doesn't Wikipedia list as an optional sub-system? Gili Trent Jarvi wrote: > > The support has been around for a long time to. I don't know the > details but the support appears to be tied to the OS. > > http://en.wikipedia.org/wiki/POSIX#POSIX_for_Windows > > On Tue, 7 Apr 2009, cowwoc wrote: > >> Trent Jarvi wrote: >>> I'm not sure what MSVC is using errno for but it should not be using >>> it except with POSIX extensions. Perhaps #undef is enough to get >>> rid of the warning and (maybe) has no ill consequences. Newer >>> windows have POSIX extensions that may show how Microsoft solved the >>> problem. >>> >>> It can probably fester. >> >> What does "newer windows" refer to in this case? I was compiling >> using Visual Studio 2008 sp1 under Windows Vista. Both are cutting >> edge technologies as far as official releases go. >> >> I think you're best suited to judge whether this warning is a big >> deal or not so I think you should see it for yourself. Please try >> firing up Visual Studio 2008 (express?) against the project I sent you. >> >> Gili >> From eranshuman at gmail.com Mon Apr 13 04:50:34 2009 From: eranshuman at gmail.com (Anshuman Srivastava) Date: Mon, 13 Apr 2009 16:20:34 +0530 Subject: [Rxtx] Send RTS /DTR signal Message-ID: <589913a50904130350n59cc51ffvbcd0a4eaefb4ce5f@mail.gmail.com> Hi, I want to send the RTS or DTR signal from the application Can anybody telll how to send the DTR /RTS signal using rxtxcomm libraries Thanks and regards -- Anshuman Srivastava "... in the end, it's not the years in your life that count. It's the life in your years." Buzz +91 9962515155 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090413/211b5ded/attachment-0004.html From ajmas at sympatico.ca Mon Apr 13 09:50:47 2009 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 13 Apr 2009 11:50:47 -0400 Subject: [Rxtx] Wiki Spam pages - need of captcha? Message-ID: Hi Trent, While checking for spam pages in the wiki I came across a page containing the following: "NOTICE: This page was created by a program as part of the Graffiti Network research project at Brown University. We have removed the data, but are unable to remove this page. We apologize for any inconveniences that our actions may have caused. For more information, please visit http://graffiti.cs.brown.edu/info/." Is there any chance we could add a captcha to account registration? Andr?-John From sguido at micromotive.net Mon Apr 13 09:46:15 2009 From: sguido at micromotive.net (Samuel Guido) Date: Mon, 13 Apr 2009 11:46:15 -0400 Subject: [Rxtx] Serial Output Stream Hangs on Windows Message-ID: <843C9F1C-72EE-4A40-B02A-3798EB0C57BF@micromotive.net> All, I am using RXTX in a small application to talk to a remote embedded device on a Windows host. All data is ASCII text. On physical comm ports, everything seems to be fine, messages are sent and received without much trouble. I am also trying to make the comm port selection automatic where I cycle through the available comm ports sending messages until I get the expected response. Unfortunately, when I query for the available comm ports, the bluetooth ports also show up. Whenever I try to send a string of characters to the bluetooth port, RXTX hangs way down in the call stack in the output stream, I believe in the DLL. I tried both the 2.1.7r2 and the 2.2pre2 releases and both have the same result. The send and receiving of messages from the comm port are in their own threads, but once the thread is blocked, I can't do anything with the comm ports since they are synchronized calls. The bluetooth ports are using a driver call "WIDCOMM" which I don't know who/what that is. This is on a IBM T42 laptop machine. Does anyone know what could be causing this? Is there a way to distinguish between bluetooth ports and physical comm ports? Please help, I am on a tight deadline and any help would greatly be appreciated. Thanks very much. Sam Guido From ajmas at sympatico.ca Mon Apr 13 11:04:24 2009 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 13 Apr 2009 13:04:24 -0400 Subject: [Rxtx] RxTX mentioned on Sun's Java Communications page Message-ID: Looks like RxTx gets some mention at Sun: Head over to the Java Communications page http://java.sun.com/products/javacomm/ and then click on Downloads and you get: " COMM API is a Java extension providing access to RS-232 serial ports and IEEE-1284 parallel ports (SPP mode). Sun Ray platform support is provided. Documentation and sample code are included, as well as interactive test utilities. API serial features provide access to: * Port settings (baud rate, parity, stop bits) * Port naming, mapping, enumeration (configurable) * Data transfer over TX, RX lines * DTR, CD, CTS, RTS and DSR signals * Hardware/Software flow-control * Receive-buffer threshold control * Asynchronous events indicating: * Data available on an RS-232 port * Port hardware line level changes * Port ownership changes within a JVM Update History: * javax.comm 3.0, Update 1 o Fixed problems locating and parsing portmap.conf * javax.comm 3.0, FCS o Redesigned portmapping and Sun Ray interoperability (see bundled documentation) * 2.0.3: o Added portmapping (comm.jar available 'as-is' for 3rd party native lib support)* Several Bugfixes to 2.0.3 (see bundled release notes) Note: Sun no longer offer's the Windows platform binaries of javax.comm, however javax.comm 2.0.3 can be used for the Windows platform, by using it in conjunction with the Win32 implementation layer provided by the RxTx project. To use that, download javax.comm for the 'generic' platform (which provides the front-end javax.comm API only, without platform specific back-end implementations bundled). Then acquire the Windows binary implementation rxtx-2.0.7pre1 from http://www.rxtx.org . " Looks like RxTx really is the closest thing we have to the 'official' implementation. From tjarvi at qbang.org Mon Apr 13 12:27:44 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 13 Apr 2009 12:27:44 -0600 (MDT) Subject: [Rxtx] RxTX mentioned on Sun's Java Communications page In-Reply-To: References: Message-ID: On Mon, 13 Apr 2009, Andre-John Mas wrote: > Looks like RxTx gets some mention at Sun: > > Head over to the Java Communications page http://java.sun.com/products/javacomm/ > and then click on Downloads and you get: > > " > COMM API is a Java extension providing access to RS-232 serial ports > and IEEE-1284 parallel ports (SPP mode). Sun Ray platform support is > provided. Documentation and sample code are included, as well as > interactive test utilities. API serial features provide access to: * > Port settings (baud rate, parity, stop bits) * Port naming, mapping, > enumeration (configurable) * Data transfer over TX, RX lines * DTR, > CD, CTS, RTS and DSR signals * Hardware/Software flow-control * > Receive-buffer threshold control * Asynchronous events indicating: * > Data available on an RS-232 port * Port hardware line level changes * > Port ownership changes within a JVM Update History: * javax.comm 3.0, > Update 1 o Fixed problems locating and parsing portmap.conf * > javax.comm 3.0, FCS o Redesigned portmapping and Sun Ray > interoperability (see bundled documentation) * 2.0.3: o Added > portmapping (comm.jar available 'as-is' for 3rd party native lib > support)* Several Bugfixes to 2.0.3 (see bundled release notes) Note: > Sun no longer offer's the Windows platform binaries of javax.comm, > however javax.comm 2.0.3 can be used for the Windows platform, by > using it in conjunction with the Win32 implementation layer provided > by the RxTx project. To use that, download javax.comm for the > 'generic' platform (which provides the front-end javax.comm API only, > without platform specific back-end implementations bundled). Then > acquire the Windows binary implementation rxtx-2.0.7pre1 from http://www.rxtx.org > .. > " > > Looks like RxTx really is the closest thing we have to the 'official' > implementation. Ugh. I don't know of any developer interest in maintaining rxtx 2.0. It would be cleaner for Sun to just openly take javax.comm for their Sun Ray project. If someone is interested in maintaining rxtx 2.0, don't be afraid to say so. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Mon Apr 13 16:04:19 2009 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 13 Apr 2009 17:04:19 -0500 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D8DDEB.5010908@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> Message-ID: <49E3B6E3.5050203@cox.net> cowwoc wrote: > Trent Jarvi wrote: >> You are responsible for cleaning up the serial ports when using threads. >> That said, if the thread did shut down, finalize should have been called >> if you are not passing the object around. See RXTXPort.java. >> >> protected void finalize() >> { >> if (debug) >> z.reportln( "RXTXPort:finalize()"); >> if( fd > 0 ) >> { >> if (debug) >> z.reportln( "RXTXPort:calling close()"); >> close(); >> } >> z.finalize(); >> } > > Two points: > > 1) One should never rely on finalizers because they may never run. A PhantomRef is the way to do this kind of cleanup in most cases. It will always fire. The real issue is that you have to understand that the on the Sun JVM, the GC can run finalization or advertise a dropped reference before an object is actually unreferenced in some cases. This happens, predominately in blocks of code where object references are short lived with no class member reference that the GC can find. When the JIT compiled code just references an object on the local stack and/or a register, the GC can prematurely attempt finalization/PhantomRef notification and result in bad things happening. The single solution to this problem is to use synchronize(obj){} at the end of the block of code that obj lives in, which keeps the object from getting reclaimed prematurely. For the sake of application sanity and recovery from erroneous code, it's almost always best to put resources like this into a map, accessed by name, and make an API method that lets you find the object by name, rather than by instance reference. Then, in your code, when you want to open a serial port, you'd do something like the following, which will close anything you already opened and then open it back up. Map ports = ...; public void closePort( String port ) { CommPort p = null; p = ports.remove(port); if( p != null ) p.close(); } public CommPort public CommPort openPort( String port, String user, int timeout ) throws IOException { closePort( port ); CommPort p = CommPortIdentifier.getPortIdentifier(port). open( user, timeout ); ports.put( port, p ); return p; } Appropriate use of synchronized(ports) may be necessary if ports is not referencing a concurrency safe Map implementation such as Hashtable or ConcurrentHashMap. Gregg Wonderly From gergg at cox.net Mon Apr 13 16:36:57 2009 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 13 Apr 2009 17:36:57 -0500 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: <49D546F8.20807@gatworks.com> <49D693BA.8060909@gatworks.com> Message-ID: <49E3BE89.4020402@cox.net> Check CTS/RTS and DTR/CD etc on the device to make sure you haven't hung the kernel trying to clean up something, but it's now waiting for CTS etc. In general, you should be careful about using HW flow control when cables can be trivially unplugged or broken. Use application layer checksums or similar things to make sure data that is flowing is sane and that buffers have not overrun, resulting in lost data. Gregg Wonderly Trent Jarvi wrote: > UTS_RELEASE is defined in now. The check really should > be removed from RXTX. It was a defensive check for wilder times when GNU > glibc did not have defines the kernel headers had so rxtx would include > the kernel headers instead. :/ > > If you don't have linux/version.h, it is generated when you configure the > kernel. make oldconfig used to do the trick. It may make sense to work > with the prerelease or CVS code. > > RXTX just assumes that flush, read and anything else the kernel exposes > may be called at anytime from any thread. There isn't a design for the > kernel interaction. There are higher level constraints put in Java to > prevent some things happening at the same time with 'synchronized.' > RXTXPort.java has all of those. > > When the port is opened, a native event thread is started which uses > select to know if an event has happened. > > BSD like systems have a native thread that fires off on write which tries > to flush() to determine when the output buffer is empty asynchronously. > > The rest is not marshaled in any fashion at the native level. T > > I think there is a lower level deadlock being triggered in flush as well. > I don't think it should be possible if everything was right underneath us. > You may want to examine the java code closer to make sure it isnt possible > the lock is there. > > > On Mon, 6 Apr 2009, Bill Johnson wrote: > >> Once it hung, three stack dumps minutes apart were exactly the same. >> I have a noticed that when it hangs, the read appears after flush() enter and >> before flush leave() that doesn't happen like: >> RXTXPort:SerialOutputStream:flush() enter >> RXTXPort:SerialInputStream:read(8192 0 8192) called >> >> When it works, flush() enter and leave happen together. It may just be because >> flush() hangs and read is the only other thread waiting to run at that point. >> I don't know much about the RXTX design and kernel interaction, just digging >> through the code some. Is there a design description somewhere? >> >> Am hung up on target system compile since UTS_RELEASE seems no longer defined for >> 2.6.18 up kernels and have not figured a good patch yet. But, that is another >> issue. >> >> Thanks for the good help. >> >> >> On Fri, Apr 3, 2009 at 6:54 PM, U. George wrote: >> I would have tried 2 or 3 "^\" . If things are stuck, then all will be >> at same 'java' instruction. If thread is moving, then one of the >> snapshots would be different. >> >> I *think* flushing/draining wont return until the kernel buffers to >> device have been accepted by device. Stuck/paused device? >> >> >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From cowwoc at bbs.darktech.org Mon Apr 13 20:41:20 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Mon, 13 Apr 2009 22:41:20 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49E3B6E3.5050203@cox.net> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49E3B6E3.5050203@cox.net> Message-ID: <49E3F7D0.5090207@bbs.darktech.org> Gregg Wonderly wrote: > A PhantomRef is the way to do this kind of cleanup in most cases. It > will always fire. The real issue is that you have to understand that > the on the Sun JVM, the GC can run finalization or advertise a dropped > reference before an object is actually unreferenced in some cases. This > happens, predominately in blocks of code where object references are > short lived with no class member reference that the GC can find. When > the JIT compiled code just references an object on the local stack > and/or a register, the GC can prematurely attempt > finalization/PhantomRef notification and result in bad things happening. I've never seen this myself. Can you reproduce it on the latest JRE? If so, this sounds like a bug to me and should be fixed. Please consider filing a bug report and telling me the bug number. I'll try running it by my Sun contacts. Gili From ferry_new2004 at yahoo.com Mon Apr 13 21:24:59 2009 From: ferry_new2004 at yahoo.com (Ferry Sumendap) Date: Mon, 13 Apr 2009 20:24:59 -0700 (PDT) Subject: [Rxtx] In Linux, RXTX serial port lib cannot send character which hex is more than 127. Message-ID: <30875.39589.qm@web33106.mail.mud.yahoo.com> Hello everybody, I have just tested the RXTXserial port library version RXTX2-1-7pre20 to send two characters which are character ascii 230 and 234. It seems that the driver somehow did not send the two characters into serial port if the Operating System is Linux Mandriva 2007 (kernel version 2.6.17-13mdv ) or Linux Mandriva 2009. I also tried the driver using same java code (java class file of the program I wrote), in Windows XP, it does work. Should I configure something (special configuration in Linux) or did I miss something ? I also have tested the latest RXTX 2.2pre2 driver, but it still have that problem. Regards, Ferry -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090413/94fdfbea/attachment-0003.html From tjarvi at qbang.org Mon Apr 13 22:01:04 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 13 Apr 2009 22:01:04 -0600 (MDT) Subject: [Rxtx] In Linux, RXTX serial port lib cannot send character which hex is more than 127. In-Reply-To: <30875.39589.qm@web33106.mail.mud.yahoo.com> References: <30875.39589.qm@web33106.mail.mud.yahoo.com> Message-ID: On Mon, 13 Apr 2009, Ferry Sumendap wrote: > Hello everybody, > > I have just tested the RXTXserial port library version? RXTX2-1-7pre20 to > send two characters which are character ascii? 230 and 234. It seems that > the driver somehow did not send the two characters into serial port if the > Operating System is Linux Mandriva 2007 (kernel version 2.6.17-13mdv > ) or Linux Mandriva 2009. > I also tried the driver using? same java code (java class file of the > program I wrote), in Windows XP,? it does work. > > Should I configure something (special configuration in Linux)? or did I miss > something ? > I also have tested the latest RXTX 2.2pre2 driver, but it still have that > problem. > Hello Ferry This sounds like an unlikely problem. Even with USB dongle issues, I can't think of a reason that would be a problem. Is this a connection at 9600 8N1? Sometimes it really is the cable. -- Trent Jarvi tjarvi at qbang.org From ferry_new2004 at yahoo.com Mon Apr 13 22:15:04 2009 From: ferry_new2004 at yahoo.com (Ferry Sumendap) Date: Mon, 13 Apr 2009 21:15:04 -0700 (PDT) Subject: [Rxtx] Fw: In Linux, RXTX serial port lib cannot send character which hex is more than 127. Message-ID: <948418.50805.qm@web33103.mail.mud.yahoo.com> ----- Forwarded Message ---- From: Ferry Sumendap To: Trent Jarvi Sent: Tuesday, April 14, 2009 11:10:04 AM Subject: Re: [Rxtx] In Linux, RXTX serial port lib cannot send character which hex is more than 127. Thank you for your answer. I use the same machine, cable and devices to test. My PC is installed with Linux Mandriva and WINDOWS. The serial port physically have no problem since using Windows, it works. I also tested the serial port using MONI (tcl based program). MONI is linux based program to send some characters to serial port. Using MONI, I sent the characters to /dev/ttyS0, and it works because the device which is plugged in /dev/ttyS0 received and answered the message. But for RXTX, some how, java based program cannot send those characters. With the same java based program, it works properly in WINDOWS and the same cable, devices, hardware specification. That's why I am curious about RXTX. Here is the serial port configuration I used. Com Port /dev/ttyS0 Baud rate 19200 Data bits 8 ( value = 8) Stop bits 1 ( value = 1) Parity None ( value = 0) Thank you very much for your response. Regards, Ferry ________________________________ From: Trent Jarvi To: Ferry Sumendap Cc: rxtx at qbang.org Sent: Tuesday, April 14, 2009 11:01:04 AM Subject: Re: [Rxtx] In Linux, RXTX serial port lib cannot send character which hex is more than 127. On Mon, 13 Apr 2009, Ferry Sumendap wrote: > Hello everybody, > > I have just tested the RXTXserial port library version RXTX2-1-7pre20 to > send two characters which are character ascii 230 and 234. It seems that > the driver somehow did not send the two characters into serial port if the > Operating System is Linux Mandriva 2007 (kernel version 2.6.17-13mdv > ) or Linux Mandriva 2009. > I also tried the driver using same java code (java class file of the > program I wrote), in Windows XP, it does work. > > Should I configure something (special configuration in Linux) or did I miss > something ? > I also have tested the latest RXTX 2.2pre2 driver, but it still have that > problem. > Hello Ferry This sounds like an unlikely problem. Even with USB dongle issues, I can't think of a reason that would be a problem. Is this a connection at 9600 8N1? Sometimes it really is the cable. -- Trent Jarvi tjarvi at qbang.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090413/27a37ea5/attachment-0003.html From ferry_new2004 at yahoo.com Mon Apr 13 22:23:53 2009 From: ferry_new2004 at yahoo.com (Ferry Sumendap) Date: Mon, 13 Apr 2009 21:23:53 -0700 (PDT) Subject: [Rxtx] In Linux, RXTX serial port lib cannot send character which hex is more than 127. In-Reply-To: References: <30875.39589.qm@web33106.mail.mud.yahoo.com> <81465.86461.qm@web33102.mail.mud.yahoo.com> Message-ID: <736778.48214.qm@web33108.mail.mud.yahoo.com> I am sorry not telling you about the configuration.. Yes I did test using the same serial port configuration, but the RXTX did not work properly. I also use "root" just in case there is security violation. If I sent another character that is below 127 (ascii < 127) the RXTX works properly either in LINUX or WINDOWS. I also cannot believe that coders of RXTX would make diffentiation between baudrate 19200 and 9600. The driver actually works very good unfortunately if the character is upper than ascii 127 (like ascii 230 and 234) it will not work. Thank you very much. Regards, Ferry ________________________________ From: Trent Jarvi To: Ferry Sumendap Cc: Trent Jarvi Sent: Tuesday, April 14, 2009 11:16:34 AM Subject: Re: [Rxtx] In Linux, RXTX serial port lib cannot send character which hex is more than 127. Hi Ferry, The only thing you mention that is not tested on a regular basis is the 19200 baudrate. There is nothing special (code wise) about that baudrate. On Mon, 13 Apr 2009, Ferry Sumendap wrote: > Thank you for your answer. > > I use the same machine, cable and devices to test. > My PC is installed with Linux Mandriva and WINDOWS. > The serial port physically have no problem since using Windows, it works. > > I also tested the serial port using MONI (tcl based program). > MONI is linux based program to send some characters to serial port. > Using MONI, I sent the characters to /dev/ttyS0, and it works because the > device which is plugged in /dev/ttyS0 received and answered the message. > > But for RXTX, some how, java based program cannot send those characters. > With the same java based program, it works properly in WINDOWS and the same > cable, devices, hardware specification. > That's why I am curious about RXTX. > > > > Here is the serial port configuration I used. > > Com Port /dev/ttyS0 > Baud rate 19200 > Data bits 8 ( value = 8) > Stop bits 1 ( value = 1) > Parity None ( value = 0) > > > > Thank you very much for your response. > > Regards, > Ferry > > > ____________________________________________________________________________ > From: Trent Jarvi > To: Ferry Sumendap > Cc: rxtx at qbang.org > Sent: Tuesday, April 14, 2009 11:01:04 AM > Subject: Re: [Rxtx] In Linux, RXTX serial port lib cannot send character > which hex is more than 127. > > > > On Mon, 13 Apr 2009, Ferry Sumendap wrote: > > > Hello everybody, > > > > I have just tested the RXTXserial port library version RXTX2-1-7pre20 to > > send two characters which are character ascii 230 and 234. It seems that > > the driver somehow did not send the two characters into serial port if the > > Operating System is Linux Mandriva 2007 (kernel version 2.6.17-13mdv > > ) or Linux Mandriva 2009. > > I also tried the driver using same java code (java class file of the > > program I wrote), in Windows XP, it does work. > > > > Should I configure something (special configuration in Linux) or did I > miss > > something ? > > I also have tested the latest RXTX 2.2pre2 driver, but it still have that > > problem. > > > > Hello Ferry > > This sounds like an unlikely problem. > > Even with USB dongle issues, I can't think of a reason that would be a > problem. Is this a connection at 9600 8N1? > > Sometimes it really is the cable. > > -- > Trent Jarvi > tjarvi at qbang.org > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090413/7a2fd5a0/attachment-0003.html From tjarvi at qbang.org Mon Apr 13 22:45:09 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 13 Apr 2009 22:45:09 -0600 (MDT) Subject: [Rxtx] In Linux, RXTX serial port lib cannot send character which hex is more than 127. In-Reply-To: <736778.48214.qm@web33108.mail.mud.yahoo.com> References: <30875.39589.qm@web33106.mail.mud.yahoo.com> <81465.86461.qm@web33102.mail.mud.yahoo.com> <736778.48214.qm@web33108.mail.mud.yahoo.com> Message-ID: This sounds like a signed vs unsigned char issue. Given that rxtx does binary read and write fine on Linux, I'm at a loss of what your problem may be. No, I don't suspect the baudrate is an issue either. On Mon, 13 Apr 2009, Ferry Sumendap wrote: > I am sorry not telling you about the configuration.. > > Yes I did test using the same serial port configuration, but the RXTX did > not work properly. > I also use "root" just in case there is security violation. > If? I sent another character that is below 127 (ascii < 127) the RXTX works > properly either in LINUX or WINDOWS. > > I also cannot believe that coders of RXTX would make diffentiation between > baudrate 19200 and 9600. > The driver actually works very good unfortunately if the character is upper > than ascii 127 (like ascii 230 and 234) it will not work. > > Thank you very much. > Regards, > > Ferry > > ____________________________________________________________________________ > From: Trent Jarvi > To: Ferry Sumendap > Cc: Trent Jarvi > Sent: Tuesday, April 14, 2009 11:16:34 AM > Subject: Re: [Rxtx] In Linux, RXTX serial port lib cannot send character > which hex is more than 127. > > > Hi Ferry, > > The only thing you mention that is not tested on a regular basis is the > 19200 baudrate.? There is nothing special (code wise) about that baudrate. > > On Mon, 13 Apr 2009, Ferry Sumendap wrote: > > > Thank you for your answer. > > > > I use the same machine, cable and devices to test. > > My PC is installed with Linux Mandriva and WINDOWS. > > The serial port physically have no problem since using Windows, it works. > > > > I also tested the serial port using MONI (tcl based program). > > MONI is linux based program to send some characters to serial port. > > Using MONI, I sent the characters to /dev/ttyS0, and it works because the > > device which is plugged in /dev/ttyS0 received and answered the message. > > > > But for RXTX, some how, java based program cannot send those characters. > > With the same java based program, it works properly in WINDOWS and the > same > > cable, devices, hardware specification. > > That's why I am curious about RXTX. > > > > > > > > Here is the serial port configuration I used. > > > > Com Port /dev/ttyS0 > > Baud rate 19200 > > Data bits 8 ( value = 8) > > Stop bits 1?? ( value = 1) > > Parity None? ( value = 0) > > > > > > > > Thank you very much for your response. > > > > Regards, > > Ferry > > > > > >___________________________________________________________________________ > _ > > From: Trent Jarvi > > To: Ferry Sumendap > > Cc: rxtx at qbang.org > > Sent: Tuesday, April 14, 2009 11:01:04 AM > > Subject: Re: [Rxtx] In Linux, RXTX serial port lib cannot send character > > which hex is more than 127. > > > > > > > > On Mon, 13 Apr 2009, Ferry Sumendap wrote: > > > > > Hello everybody, > > > > > > I have just tested the RXTXserial port library version? RXTX2-1-7pre20 > to > > > send two characters which are character ascii? 230 and 234. It seems > that > > > the driver somehow did not send the two characters into serial port if > the > > > Operating System is Linux Mandriva 2007 (kernel version 2.6.17-13mdv > > > ) or Linux Mandriva 2009. > > > I also tried the driver using? same java code (java class file of the > > > program I wrote), in Windows XP,? it does work. > > > > > > Should I configure something (special configuration in Linux)? or did I > > miss > > > something ? > > > I also have tested the latest RXTX 2.2pre2 driver, but it still have > that > > > problem. > > > > > > > Hello Ferry > > > > This sounds like an unlikely problem. > > > > Even with USB dongle issues, I can't think of a reason that would be a > > problem.? Is this a connection at 9600 8N1? > > > > Sometimes it really is the cable. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > > > > > > > > From ilkka at myller.com Mon Apr 13 23:12:16 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 14 Apr 2009 08:12:16 +0300 Subject: [Rxtx] In Linux, RXTX serial port lib cannot send character which hex is more than 127. In-Reply-To: References: <30875.39589.qm@web33106.mail.mud.yahoo.com> <81465.86461.qm@web33102.mail.mud.yahoo.com> <736778.48214.qm@web33108.mail.mud.yahoo.com> Message-ID: Hi, Another suggestion: incorrect java byte casting. Java byte type has a range from -128 to 127. I've seen people assume range of 0 - 255. Incorrect integer casting with bytes is a common mistake is to cause those >127 ascii issues. Could it be? (int)b versus (int)(b & 0xFF) -- I Trent Jarvi kirjoitti 14.4.2009 kello 7.45: > > This sounds like a signed vs unsigned char issue. Given that rxtx > does binary read and write fine on Linux, I'm at a loss of what your > problem may be. > > No, I don't suspect the baudrate is an issue either. > > On Mon, 13 Apr 2009, Ferry Sumendap wrote: > >> I am sorry not telling you about the configuration.. >> Yes I did test using the same serial port configuration, but the >> RXTX did >> not work properly. >> I also use "root" just in case there is security violation. >> If I sent another character that is below 127 (ascii < 127) the >> RXTX works >> properly either in LINUX or WINDOWS. >> I also cannot believe that coders of RXTX would make diffentiation >> between >> baudrate 19200 and 9600. >> The driver actually works very good unfortunately if the character >> is upper >> than ascii 127 (like ascii 230 and 234) it will not work. >> Thank you very much. >> Regards, >> Ferry >> ____________________________________________________________________________ >> From: Trent Jarvi >> To: Ferry Sumendap >> Cc: Trent Jarvi >> Sent: Tuesday, April 14, 2009 11:16:34 AM >> Subject: Re: [Rxtx] In Linux, RXTX serial port lib cannot send >> character >> which hex is more than 127. >> Hi Ferry, >> The only thing you mention that is not tested on a regular basis is >> the >> 19200 baudrate. There is nothing special (code wise) about that >> baudrate. >> On Mon, 13 Apr 2009, Ferry Sumendap wrote: >> > Thank you for your answer. >> > >> > I use the same machine, cable and devices to test. >> > My PC is installed with Linux Mandriva and WINDOWS. >> > The serial port physically have no problem since using Windows, >> it works. >> > >> > I also tested the serial port using MONI (tcl based program). >> > MONI is linux based program to send some characters to serial port. >> > Using MONI, I sent the characters to /dev/ttyS0, and it works >> because the >> > device which is plugged in /dev/ttyS0 received and answered the >> message. >> > >> > But for RXTX, some how, java based program cannot send those >> characters. >> > With the same java based program, it works properly in WINDOWS >> and the >> same >> > cable, devices, hardware specification. >> > That's why I am curious about RXTX. >> > >> > >> > >> > Here is the serial port configuration I used. >> > >> > Com Port /dev/ttyS0 >> > Baud rate 19200 >> > Data bits 8 ( value = 8) >> > Stop bits 1 ( value = 1) >> > Parity None ( value = 0) >> > >> > >> > >> > Thank you very much for your response. >> > >> > Regards, >> > Ferry >> > >> > >> > >> ___________________________________________________________________________ >> _ >> > From: Trent Jarvi >> > To: Ferry Sumendap >> > Cc: rxtx at qbang.org >> > Sent: Tuesday, April 14, 2009 11:01:04 AM >> > Subject: Re: [Rxtx] In Linux, RXTX serial port lib cannot send >> character >> > which hex is more than 127. >> > >> > >> > >> > On Mon, 13 Apr 2009, Ferry Sumendap wrote: >> > >> > > Hello everybody, >> > > >> > > I have just tested the RXTXserial port library version >> RXTX2-1-7pre20 >> to >> > > send two characters which are character ascii 230 and 234. It >> seems >> that >> > > the driver somehow did not send the two characters into serial >> port if >> the >> > > Operating System is Linux Mandriva 2007 (kernel version >> 2.6.17-13mdv >> > > ) or Linux Mandriva 2009. >> > > I also tried the driver using same java code (java class file >> of the >> > > program I wrote), in Windows XP, it does work. >> > > >> > > Should I configure something (special configuration in Linux) >> or did I >> > miss >> > > something ? >> > > I also have tested the latest RXTX 2.2pre2 driver, but it still >> have >> that >> > > problem. >> > > >> > >> > Hello Ferry >> > >> > This sounds like an unlikely problem. >> > >> > Even with USB dongle issues, I can't think of a reason that would >> be a >> > problem. Is this a connection at 9600 8N1? >> > >> > Sometimes it really is the cable. >> > >> > -- >> > Trent Jarvi >> > tjarvi at qbang.org >> > >> > >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From sunil at saltriver.com Tue Apr 14 01:06:38 2009 From: sunil at saltriver.com (Sunil Bhambani) Date: Tue, 14 Apr 2009 07:06:38 -0000 Subject: [Rxtx] RxTx on Mac for USB Message-ID: <1080422816.3127.6.camel@localhost.localdomain> Hi, I have a GPS device which is USB device. I want to use that device on Mac System and Java as the programming language. I have read that USB support through RxTx on Mac is not there. Is this correct? I would like to read the data that comes to GPS device. Can some connector be used to communicate with that device. For example USB to RJ11 or USB to serial connector? Are this connectors reliable enough to be used? Hope to get the reply soon. -- Thank & Regards Sunil -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090414/295ccb1d/attachment-0002.html From helgeingvart at gmail.com Tue Apr 14 01:43:04 2009 From: helgeingvart at gmail.com (Helge Fredriksen) Date: Tue, 14 Apr 2009 09:43:04 +0200 Subject: [Rxtx] IO exceptions on 2.2pre2 In-Reply-To: References: <306B677E-9207-44CB-81CD-787A50DB7DA6@myller.com> Message-ID: FYI: There seem to be success on this problem by switching to your commercial counterpart from SerialIO (http://www.serialio.com). A FTDI only problem? Best regards, Helge Fredriksen On Sat, Mar 28, 2009 at 5:32 PM, Helge Fredriksen wrote: > Thanks for your suggestions, > > We have tried switching off the power saving settings as recommended, but > regrettably we see the same things happening still. > > The FTDI device is not connected directly to USB hubs, no. > > Someone have any more ideas? > > Best regards, > Helge Fredriksen > > > On Tue, Mar 24, 2009 at 9:27 AM, Ilkka Myller wrote: > >> Hi Helge, >> >> I am not sure if this will help, but you could try this: >> >> echo on > /sys/bus/usb/devices//power/level >> echo 0 > /sys/bus/usb/devices//power/autosuspend >> >> is the USB-bus device id of your FTDI adapter (bus-device, for >> example "2-2") >> >> This will disable USB power saving/autosuspend of FTDI USB-device. >> I've seen some some systems where this helps with FTDI-adapter connection >> drops. >> >> Also: is your FTDI device directly connected to PC's USB root hub? If not, >> test that too. >> >> >> -- >> I >> >> (replace with the usb bus device id of your FTDI serial >> adapter) >> >> Helge Fredriksen kirjoitti 24.3.2009 kello 9.45: >> >> Hello! >> >> Here's the device details: >> >> FT232R is a USB to serial UART interface. >> >> Link to componentt: http://www.ftdichip.com/Products/FT232R.htm >> >> Regards, >> Helge Fredriksen >> >> On Tue, Mar 24, 2009 at 12:05 AM, Trent Jarvi wrote: >> >>> >>> >>> On Mon, 23 Mar 2009, Helge Fredriksen wrote: >>> >>> Hello again. >>>> >>>> I'm having a bit trouble with the 2.2pre2 version it seems. I'm having >>>> an >>>> application running on Ubuntu 8.10 that seem to run stable but after an >>>> hour >>>> or so the application breaks down with lot's of IO exceptions like this: >>>> >>>> java.io.IOException: Input/output error in nativeavailable >>>> at gnu.io.RXTXPort.nativeavailable(Native Method) >>>> at gnu.io.RXTXPort$SerialInputStream.available(RXTXPort.java:1596) >>>> >>>> atcom.poseidon.usb.UsbInterface$MySerialPortEventListener.serialEvent(UsbInte >>>> rface.java:251) >>>> at gnu.io.RXTXPort.sendEvent(RXTXPort.java:772) >>>> at gnu.io.RXTXPort.eventLoop(Native Method) >>>> at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1641) >>>> >>>> Any ideas? >>>> >>> >>> Hi Helge, >>> >>> It sounds like the file descriptor (USB driver) is in an invalid state. >>> >>> What can you tell us about the USB dongle? Is it bluetooth? Do you know >>> what chipset is in it? >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090414/e2c97c4f/attachment-0003.html From Steffen.DETTMER at ingenico.com Tue Apr 14 02:21:35 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 14 Apr 2009 10:21:35 +0200 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49E3F7D0.5090207@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49E3B6E3.5050203@cox.net> <49E3F7D0.5090207@bbs.darktech.org> Message-ID: <20090414082135.GG5090@elberon.bln.de.ingenico.com> * cowwoc wrote on Mon, Apr 13, 2009 at 22:41 -0400: > Gregg Wonderly wrote: > > The real issue is that you have to understand that > > the on the Sun JVM, the GC can run finalization or advertise a dropped > > reference before an object is actually unreferenced in some cases. > > I've never seen this myself. Can you reproduce it on the latest JRE? If > so, this sounds like a bug to me and should be fixed. Please consider > filing a bug report and telling me the bug number. I'll try running it > by my Sun contacts. I found some general hints here: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2261.html Traditional finalization in garbage collected languages is defined in terms of object reachability. But objects can easily become "unreachable" earlier than the programmer expects, due to compiler optimizations. An object may be logically in use long past the last point at which the memory associated with the object is accessed or referenced by any pointers visible to the garbage collector. In the worst case, the compiler might decide to store all the fields of an object in registers, and then observe that the "this" pointer for the newly allocated memory is dead immediately after the allocation, and hence not save it anywhere. The garbage collector, even if run immediately after the allocation, would then discover that the memory object is no longer reachable, and run the finalizer immediately, in spite of the fact that the object fields are still in use, and in fact may remain in use after the finalizer has run. However, if this would be a so general weakness that someone is adviced to store object instances in collections instead of using members or having the references on the stack - even if used correctly - I think it would be a major weakness which probably had been fixed, because otherwise raping collections as such workarounds would be commonly visible. BTW, I think the citation above is wrong if the optimised member values are used after that. The destructor / finalizer may set all fields to null or so and (ordinary) optimizers should not affect the behavior of correct and usual code I think. (ohh, and Cowwoc, forced-GC and to forbid the developer to control lifecycle in Java is considered a feature, not a bug! -- SCNR) oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From michael.erskine at ketech.com Tue Apr 14 02:50:53 2009 From: michael.erskine at ketech.com (Michael Erskine) Date: Tue, 14 Apr 2009 09:50:53 +0100 Subject: [Rxtx] Wiki Spam pages - need of captcha? In-Reply-To: References: Message-ID: <06BA3262D918014F9183B66425D5A8D45FA42D88FB@no-sv-03.ketech.local> All, See http://tech.slashdot.org/article.pl?sid=09/04/13/0120226 for details of this particular use of open wiki sites and the apology. Regards, Michael Erskine. From Steffen.DETTMER at ingenico.com Tue Apr 14 04:27:53 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 14 Apr 2009 12:27:53 +0200 Subject: [Rxtx] In Linux, RXTX serial port lib cannot send character which hex is more than 127. In-Reply-To: <30875.39589.qm@web33106.mail.mud.yahoo.com> References: <30875.39589.qm@web33106.mail.mud.yahoo.com> Message-ID: <20090414102753.GI5090@elberon.bln.de.ingenico.com> * Ferry Sumendap wrote on Mon, Apr 13, 2009 at 20:24 -0700: > I have just tested the RXTXserial port library version > RXTX2-1-7pre20 to send two characters which are character ascii > 230 and 234. Can you send -26 and -22 instead? Then it probably is a casting issue (as Trent and Ilkka already considered). oki, Steffen End of message. ------------------------------------------------------------------->8======= About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Bob_Jacobsen at lbl.gov Tue Apr 14 08:31:13 2009 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Tue, 14 Apr 2009 07:31:13 -0700 Subject: [Rxtx] RxTx on Mac for USB In-Reply-To: <1080422816.3127.6.camel@localhost.localdomain> References: <1080422816.3127.6.camel@localhost.localdomain> Message-ID: At 2:56 AM +0530 3/28/04, Sunil Bhambani wrote: >Hi, > >I have a GPS device which is USB device. I want to use that device >on Mac System and Java as the programming language. I have read that >USB support through RxTx on Mac is not there. Is this correct? I >would like to read the data that comes to GPS device. Can some >connector be used to communicate with that device. For example USB >to RJ11 or USB to serial connector? Are this connectors reliable >enough to be used? If the GPS device looks like a serial device to Mac OS X (Darwin), RXTX will work fine. To check: *) Unplug your device. *) Do the following command line, and keep the output: ls -lt /dev/ | head -10 *) Plug in your device and wait a couple seconds *) Repeat the above command line, and see if there are any new entries at the top of the output. The new entries, if any, are how your GPS device was mounted. If the new device(s) start with /dev/tty or /dev/cu, you'll be able to use RXTX. As a next step, you can use the "cu" command to try to talk to your GPS device as serial device. For example, cu -s 19200 -l /dev/tty.usbserial-LWPMMU13 You can download RXTX installers for various MacOS X version from here: But note these are for RXTX 2.0 versions (javax.comm package). Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From sunil at saltriver.com Wed Apr 15 00:06:40 2009 From: sunil at saltriver.com (Sunil Bhambani) Date: Wed, 15 Apr 2009 06:06:40 -0000 Subject: [Rxtx] RxTx on Mac for USB In-Reply-To: References: <1080422816.3127.6.camel@localhost.localdomain> Message-ID: <1080505612.2924.9.camel@localhost.localdomain> On Tue, 2009-04-14 at 07:31 -0700, Bob Jacobsen wrote: > At 2:56 AM +0530 3/28/04, Sunil Bhambani wrote: > >Hi, > > > >I have a GPS device which is USB device. I want to use that device > >on Mac System and Java as the programming language. I have read that > >USB support through RxTx on Mac is not there. Is this correct? I > >would like to read the data that comes to GPS device. Can some > >connector be used to communicate with that device. For example USB > >to RJ11 or USB to serial connector? Are this connectors reliable > >enough to be used? > > If the GPS device looks like a serial device to Mac OS X (Darwin), > RXTX will work fine. > > To check: > > *) Unplug your device. > *) Do the following command line, and keep the output: > > ls -lt /dev/ | head -10 > > *) Plug in your device and wait a couple seconds > > *) Repeat the above command line, and see if there are any new > entries at the top of the output. > > The new entries, if any, are how your GPS device was mounted. If the > new device(s) start with /dev/tty or /dev/cu, you'll be able to use > RXTX. > > As a next step, you can use the "cu" command to try to talk to your > GPS device as serial device. For example, > > cu -s 19200 -l /dev/tty.usbserial-LWPMMU13 > > You can download RXTX installers for various MacOS X version from here: > > > > But note these are for RXTX 2.0 versions (javax.comm package). > > Bob Hi Bob, I am using Mac 10.5 and I have done what you have said. I get the following output total 4 crw--w---- 1 Saltriver tty 16, 0 Apr 15 11:13 ttys000 crw-rw-rw- 1 root wheel 8, 0 Apr 15 11:13 random crw-rw-rw- 1 root tty 15, 1 Apr 15 11:13 ptmx crw------- 1 Saltriver staff 0, 0 Apr 15 11:10 console crw-rw-rw- 1 root wheel 3, 2 Apr 15 10:58 null crw------- 1 root wheel 23, 1 Apr 15 10:32 bpf1 crw------- 1 root wheel 23, 0 Apr 15 10:32 bpf0 crw------- 1 root wheel 11, 0 Apr 15 10:31 autofs crw------- 1 root wheel 17, 0 Apr 15 10:31 autofs_control saltriver-infosystemss-mac-mini:~ Saltriver$ ls -lt /dev/ | head -10 total 4 crw--w---- 1 Saltriver tty 16, 0 Apr 15 11:16 ttys000 crw-rw-rw- 1 root tty 15, 1 Apr 15 11:16 ptmx crw-rw-rw- 1 root wheel 8, 0 Apr 15 11:13 random crw------- 1 Saltriver staff 0, 0 Apr 15 11:10 console crw-rw-rw- 1 root wheel 3, 2 Apr 15 10:58 null crw------- 1 root wheel 23, 1 Apr 15 10:32 bpf1 crw------- 1 root wheel 23, 0 Apr 15 10:32 bpf0 crw------- 1 root wheel 11, 0 Apr 15 10:31 autofs crw------- 1 root wheel 17, 0 Apr 15 10:31 autofs_control I think the output is same in both. Is there any way of mounting that device. I am very new to Mac. I am using RXTX 2.1 without javax.comm package. I have tried the same code in fedora and it ran successfully. I have tried inserting pen drive in the USB port and it was detected. Hope to get a quick reply from you. Thanks & Regards Sunil -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090415/19e599e5/attachment-0001.html From Bob_Jacobsen at lbl.gov Wed Apr 15 03:43:26 2009 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Wed, 15 Apr 2009 02:43:26 -0700 Subject: [Rxtx] RxTx on Mac for USB In-Reply-To: <1080505612.2924.9.camel@localhost.localdomain> References: <1080422816.3127.6.camel@localhost.localdomain> <1080505612.2924.9.camel@localhost.localdomain> Message-ID: At 1:56 AM +0530 3/29/04, Sunil Bhambani wrote: > >I am using Mac 10.5 and I have done what you have said. I get the >following output > >total 4 >crw--w---- 1 Saltriver tty 16, 0 Apr 15 11:13 ttys000 >crw-rw-rw- 1 root wheel 8, 0 Apr 15 11:13 random >crw-rw-rw- 1 root tty 15, 1 Apr 15 11:13 ptmx >crw------- 1 Saltriver staff 0, 0 Apr 15 11:10 console ... >saltriver-infosystemss-mac-mini:~ Saltriver$ ls -lt /dev/ | head -10 >total 4 >crw--w---- 1 Saltriver tty 16, 0 Apr 15 11:16 ttys000 >crw-rw-rw- 1 root tty 15, 1 Apr 15 11:16 ptmx >crw-rw-rw- 1 root wheel 8, 0 Apr 15 11:13 random >crw------- 1 Saltriver staff 0, 0 Apr 15 11:10 console ... >I think the output is same in both. Is there any way of mounting that device. You're going to need a driver of some sort that will make the GPS unit appear as a serial device. > I am very new to Mac. I am using RXTX 2.1 without javax.comm package. This problem is happening before RXTX can do anything at all. Unless there's a device in /dev, RXTX can't even begin to be involved. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From cowwoc at bbs.darktech.org Wed Apr 15 09:08:21 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Wed, 15 Apr 2009 11:08:21 -0400 Subject: [Rxtx] RxTX mentioned on Sun's Java Communications page In-Reply-To: References: Message-ID: <49E5F865.1030206@bbs.darktech.org> >> Looks like RxTx really is the closest thing we have to the 'official' >> implementation. > > Ugh. I don't know of any developer interest in maintaining rxtx 2.0. It > would be cleaner for Sun to just openly take javax.comm for their Sun Ray > project. > > If someone is interested in maintaining rxtx 2.0, don't be afraid to say > so. Just curious, why not have the javax.comm layer just call gnu.io under the hood? This will make require no real work to maintain it even if the underlying implementation keeps on changing. From what I've seen so far the difference between the two APIs is minimal in most places. Gili From Kustaa.Nyholm at planmeca.com Wed Apr 15 09:42:33 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 15 Apr 2009 18:42:33 +0300 Subject: [Rxtx] Java5 support In-Reply-To: <49D7CD82.1040904@bbs.darktech.org> Message-ID: A recent post reminded me of this old thread that I do not think got any replies. Here is my take on the subject (of improving the API): Please do not 'improve' the API! Serial port is an old, simple and mature thing. Let's keep it that way. Very little will be gained by 'improving' it. It is already too bad that Sun spoiled the internals of javax.comm in version 3,0 so that the gnu.io package had to be coined. That is a nuisance but nothing compared to what happens if we start 'improve' the API and make it incompatible with Java Comm API. Even additions should be resisted as this will encourage people to write code that is not compatible with the 'standard' Java Comm API. The world does not need more standards but better compliance to existing standards. If someone feels things like generics/iterators for are needed it is simple to wrap the rxtx or java comm classes into classes to implement these new language features without changing the API. rxtx us great and many thanks and cudos to the maintainers and creators but it is lamentable that something this basic needs to be addressed outside standard JRE. Not to mention being able to do basic USB stuff in Java/std JRE in cross platform deployable fashion. br Kusti > From: cowwoc > Date: Sun, 5 Apr 2009 00:13:38 +0300 > To: > Conversation: [Rxtx] Java5 support > Subject: [Rxtx] Java5 support > > > > Now that you dropped javax.comm support, how about improving the API > by replacing Enumation by Iterator, int by enum, and using Generics? It > would improve the usability of the API. > > Gili > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From cowwoc at bbs.darktech.org Wed Apr 15 11:35:03 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Wed, 15 Apr 2009 13:35:03 -0400 Subject: [Rxtx] YACK Message-ID: <49E61AC7.2060701@bbs.darktech.org> Hi, Please increase the YACK() buffer size from 80 characters to 160. My long paths lead to the following kinds of errors: Error 0x5 at c:\users\gili\documents\rxtx\rxtx-devel\src\termios.c(892): AccessError 0x5 at c:\users\gili\documents\rxtx\rxtx-devel\src\termios.c(892): Access Thanks, Gili From talberts at msiscales.com Wed Apr 15 12:22:20 2009 From: talberts at msiscales.com (Tim Alberts) Date: Wed, 15 Apr 2009 11:22:20 -0700 Subject: [Rxtx] RxTX mentioned on Sun's Java Communications page In-Reply-To: <49E5F865.1030206@bbs.darktech.org> References: <49E5F865.1030206@bbs.darktech.org> Message-ID: <49E625DC.80509@msiscales.com> cowwoc wrote: >>> Looks like RxTx really is the closest thing we have to the 'official' >>> implementation. >>> >> Ugh. I don't know of any developer interest in maintaining rxtx 2.0. It >> would be cleaner for Sun to just openly take javax.comm for their Sun Ray >> project. >> >> If someone is interested in maintaining rxtx 2.0, don't be afraid to say >> so. >> > > Just curious, why not have the javax.comm layer just call gnu.io under > the hood? This will make require no real work to maintain it even if the > underlying implementation keeps on changing. From what I've seen so far > the difference between the two APIs is minimal in most places. > > Gili I can't help but get in on this discussion thread. I starting using javax.comm from Sun and I've got a huge project that is entirely based on it now. Sun dropped support for windows which is a huge disappointment for me. I read Sun's page that if you want serial ports on Java with Windows, go to RXTX. I did this. In my experiments I've found by trial and error (and by discussion on this list) that under the hood, Sun javax.comm and RXTX gnu.io are completely different. So since Sun doesn't care about anyone who doesn't use their platforms (or at least anyone that uses Windows). I would argue that RXTX has no obligation to Sun. On another note, I have yet to see (or get) RXTX to work in my code that works perfectly fine using the old Sun javax.comm for windows binaries that I am forced to continue to run on. -------------- next part -------------- A non-text attachment was scrubbed... Name: talberts.vcf Type: text/x-vcard Size: 337 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20090415/a373e7f2/attachment-0001.vcf From cowwoc at bbs.darktech.org Wed Apr 15 13:13:03 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Wed, 15 Apr 2009 15:13:03 -0400 Subject: [Rxtx] Java5 support In-Reply-To: References: Message-ID: <49E631BF.9040501@bbs.darktech.org> > > A recent post reminded me of this old thread that I do not think got any > replies. > > Here is my take on the subject (of improving the API): > > Please do not 'improve' the API! > > Serial port is an old, simple and mature thing. Let's keep it that way. > Very little will be gained by 'improving' it. It is already too bad > that Sun spoiled the internals of javax.comm in version 3,0 so that the > gnu.io package had to be coined. That is a nuisance but nothing compared to > what happens if we start 'improve' the API and make it incompatible with > Java Comm API. > > Even additions should be resisted as this will encourage people to write > code that is not compatible with the 'standard' Java Comm API. The world > does not need more standards but better compliance to existing standards. > > If someone feels things like generics/iterators for are needed it is simple > to wrap the rxtx or java comm classes into classes to implement these > new language features without changing the API. > > rxtx us great and many thanks and cudos to the maintainers and creators but > it is lamentable that something this basic needs to be addressed outside > standard JRE. Not to mention being able to do basic USB stuff in Java/std > JRE in cross platform deployable fashion. > > br Kusti Hi Kusti, I must be missing something... I thought the entire point of forking off gnu.io was to innovate the API in a different direction than javax.comm, otherwise why wouldn't you stick to the standard API? Thanks, Gili From cowwoc at bbs.darktech.org Wed Apr 15 14:57:46 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Wed, 15 Apr 2009 16:57:46 -0400 Subject: [Rxtx] Timeout patch Message-ID: <49E64A4A.1050806@bbs.darktech.org> Hi, Please review the attached patch. - fixes disableReceiveTimeout() so reads now block until data is available. - receive timeouts and threshold handling is now more consistent across all implementations Gili -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: timeout.patch Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20090415/6815e522/attachment.pl From bschlining at gmail.com Wed Apr 15 17:15:10 2009 From: bschlining at gmail.com (Brian Schlining) Date: Wed, 15 Apr 2009 16:15:10 -0700 Subject: [Rxtx] Timeout patch In-Reply-To: <49E64A4A.1050806@bbs.darktech.org> References: <49E64A4A.1050806@bbs.darktech.org> Message-ID: > > - fixes disableReceiveTimeout() so reads now block until data is available. Finally!! Thanks for submitting this patch. Hopefully it'll be integrated soon. Cheers -- B ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090415/a4143da7/attachment.html From tristan.dyer at cgi.com Wed Apr 15 17:32:43 2009 From: tristan.dyer at cgi.com (Dyer, Tristan) Date: Wed, 15 Apr 2009 19:32:43 -0400 Subject: [Rxtx] Java5 support In-Reply-To: <49E631BF.9040501@bbs.darktech.org> References: <49E631BF.9040501@bbs.darktech.org> Message-ID: <9DA32B4D8579AF44AD96C1CC2E9C518D0346E9EB@MTL-MSG-02.cgiclients.com> That's weird. All I had to do to get my project running on RxTx was to change javax.comm to gnu.io I assume the reason for the fork to gnu.io was precisely to preserve compatibility with javax.comm. Unless Sun is willing to give you a TCK (or someone wants to pay for it) you wouldn't be able to provide any of the "new" javax.comm 3.0 feature set to windows and call it javax.comm, and as a side effect you get to keep the api consistent across platforms as well. Apache has been in a pissing fight with Sun for a couple years about this in regards to Harmony. As I remember rxtx was a lower level that suns CommAPI jar could talk to, to provide javax.comm on linux originally. With sun only providing CommAPI for some environments it became necessary to fork. At least that's how I assume it got here. Tristan -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of cowwoc Sent: Wednesday, April 15, 2009 4:13 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Java5 support > > A recent post reminded me of this old thread that I do not think got any > replies. > > Here is my take on the subject (of improving the API): > > Please do not 'improve' the API! > > Serial port is an old, simple and mature thing. Let's keep it that way. > Very little will be gained by 'improving' it. It is already too bad > that Sun spoiled the internals of javax.comm in version 3,0 so that the > gnu.io package had to be coined. That is a nuisance but nothing compared to > what happens if we start 'improve' the API and make it incompatible with > Java Comm API. > > Even additions should be resisted as this will encourage people to write > code that is not compatible with the 'standard' Java Comm API. The world > does not need more standards but better compliance to existing standards. > > If someone feels things like generics/iterators for are needed it is simple > to wrap the rxtx or java comm classes into classes to implement these > new language features without changing the API. > > rxtx us great and many thanks and cudos to the maintainers and creators but > it is lamentable that something this basic needs to be addressed outside > standard JRE. Not to mention being able to do basic USB stuff in Java/std > JRE in cross platform deployable fashion. > > br Kusti Hi Kusti, I must be missing something... I thought the entire point of forking off gnu.io was to innovate the API in a different direction than javax.comm, otherwise why wouldn't you stick to the standard API? Thanks, Gili _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Apr 15 17:48:20 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 15 Apr 2009 17:48:20 -0600 (MDT) Subject: [Rxtx] Timeout patch In-Reply-To: <49E64A4A.1050806@bbs.darktech.org> References: <49E64A4A.1050806@bbs.darktech.org> Message-ID: On Wed, 15 Apr 2009, cowwoc wrote: > Hi, > > Please review the attached patch. > > - fixes disableReceiveTimeout() so reads now block until data is available. > - receive timeouts and threshold handling is now more consistent across all > implementations > Hi Gili, This looks good to me. One 'minor' issue is that you are returning -1 instead of 0 now on timeout. It is fair to say timeouts are the same as the end of input but that is new behavior in rxtx we should warn existing users about so they can adjust their code. -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Wed Apr 15 17:52:46 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Wed, 15 Apr 2009 19:52:46 -0400 Subject: [Rxtx] Timeout patch In-Reply-To: References: <49E64A4A.1050806@bbs.darktech.org> Message-ID: <49E6734E.4010809@bbs.darktech.org> Actually returning -1 on timeout would be bug on my part. I believe that InputStream is expecting us to return 0 in such a case. Which part of my patch changes the return value? Thanks, Gili Trent Jarvi wrote: > On Wed, 15 Apr 2009, cowwoc wrote: > >> Hi, >> >> Please review the attached patch. >> >> - fixes disableReceiveTimeout() so reads now block until data is >> available. >> - receive timeouts and threshold handling is now more consistent >> across all implementations >> > > Hi Gili, > > This looks good to me. One 'minor' issue is that you are returning -1 > instead of 0 now on timeout. It is fair to say timeouts are the same as > the end of input but that is new behavior in rxtx we should warn > existing users about so they can adjust their code. > > -- > Trent Jarvi > tjarvi at qbang.org > From tjarvi at qbang.org Wed Apr 15 18:38:01 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 15 Apr 2009 18:38:01 -0600 (MDT) Subject: [Rxtx] Java5 support In-Reply-To: <9DA32B4D8579AF44AD96C1CC2E9C518D0346E9EB@MTL-MSG-02.cgiclients.com> References: <49E631BF.9040501@bbs.darktech.org> <9DA32B4D8579AF44AD96C1CC2E9C518D0346E9EB@MTL-MSG-02.cgiclients.com> Message-ID: The project isn't interested in breaking projects or changing the API. That said, we do allow some extensions to be added that are clearly marked as such. These extensions are all in the weird science category - they are not alternatives to doing what the API can already do or even something many people would want to use some of the time. The gnu.io namespace is used to avoid polluting of the javax.comm namespace. There are a number of reasons why we could be concerned about using javax.comm including political and/or legal questions but the main reason is a project like rxtx should do no harm. On Wed, 15 Apr 2009, Dyer, Tristan wrote: > That's weird. > > All I had to do to get my project running on RxTx was to change > javax.comm to gnu.io > > I assume the reason for the fork to gnu.io was precisely to preserve > compatibility with javax.comm. Unless Sun is willing to give you a TCK > (or someone wants to pay for it) you wouldn't be able to provide any of > the "new" javax.comm 3.0 feature set to windows and call it javax.comm, > and as a side effect you get to keep the api consistent across platforms > as well. Apache has been in a pissing fight with Sun for a couple years > about this in regards to Harmony. > > As I remember rxtx was a lower level that suns CommAPI jar could talk > to, to provide javax.comm on linux originally. With sun only providing > CommAPI for some environments it became necessary to fork. > > At least that's how I assume it got here. > > Tristan > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > Of cowwoc > Sent: Wednesday, April 15, 2009 4:13 PM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Java5 support > >> >> A recent post reminded me of this old thread that I do not think got > any >> replies. >> >> Here is my take on the subject (of improving the API): >> >> Please do not 'improve' the API! >> >> Serial port is an old, simple and mature thing. Let's keep it that > way. >> Very little will be gained by 'improving' it. It is already too bad >> that Sun spoiled the internals of javax.comm in version 3,0 so that > the >> gnu.io package had to be coined. That is a nuisance but nothing > compared to >> what happens if we start 'improve' the API and make it incompatible > with >> Java Comm API. >> >> Even additions should be resisted as this will encourage people to > write >> code that is not compatible with the 'standard' Java Comm API. The > world >> does not need more standards but better compliance to existing > standards. >> >> If someone feels things like generics/iterators for are needed it is > simple >> to wrap the rxtx or java comm classes into classes to implement these >> new language features without changing the API. >> >> rxtx us great and many thanks and cudos to the maintainers and > creators but >> it is lamentable that something this basic needs to be addressed > outside >> standard JRE. Not to mention being able to do basic USB stuff in > Java/std >> JRE in cross platform deployable fashion. >> >> br Kusti > > Hi Kusti, > > I must be missing something... I thought the entire point of forking > > off gnu.io was to innovate the API in a different direction than > javax.comm, otherwise why wouldn't you stick to the standard API? > > Thanks, > Gili > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Wed Apr 15 18:53:42 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 15 Apr 2009 18:53:42 -0600 (MDT) Subject: [Rxtx] Timeout patch In-Reply-To: <49E6734E.4010809@bbs.darktech.org> References: <49E64A4A.1050806@bbs.darktech.org> <49E6734E.4010809@bbs.darktech.org> Message-ID: Hi Gili, I guess the documentation just needs to be clear and consistant (which it really wasn't before). This is what caught my eye but looking above it, I see the previous documentation mentions -1 in places too. -*timeout threshold Behavior -*------------------------------------------------------------------------ -*0 0 blocks until 1 byte is available -*>0 0 blocks until timeout occurs, returns 0 on timeout -*>0 >0 blocks until timeout or reads threshold bytes, - returns 0 on timeout -*0 >0 blocks until reads threshold bytes - */ + * timeout threshold Behavior + * --------------------------------------------------------------------------- + * < 0 <= 0 blocks until any data is available. + * < 0 > 0 blocks until {@code min(threshold, b.len)} bytes are available. + * >=0 <=0 blocks for {@code timeout} ms or until any data is available. Returns -1 on timeout. + * >=0 > 0 blocks for {@code timeout} ms or until {@code min(threshold, b.len)} bytes are available. Returns -1 on timeout. On Wed, 15 Apr 2009, cowwoc wrote: > > Actually returning -1 on timeout would be bug on my part. I believe > that InputStream is expecting us to return 0 in such a case. Which part of my > patch changes the return value? > > Thanks, > Gili > > Trent Jarvi wrote: >> On Wed, 15 Apr 2009, cowwoc wrote: >> >>> Hi, >>> >>> Please review the attached patch. >>> >>> - fixes disableReceiveTimeout() so reads now block until data is >>> available. >>> - receive timeouts and threshold handling is now more consistent across >>> all implementations >>> >> >> Hi Gili, >> >> This looks good to me. One 'minor' issue is that you are returning -1 >> instead of 0 now on timeout. It is fair to say timeouts are the same as >> the end of input but that is new behavior in rxtx we should warn existing >> users about so they can adjust their code. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> > From cowwoc at bbs.darktech.org Wed Apr 15 19:26:28 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Wed, 15 Apr 2009 21:26:28 -0400 Subject: [Rxtx] Timeout patch In-Reply-To: References: <49E64A4A.1050806@bbs.darktech.org> <49E6734E.4010809@bbs.darktech.org> Message-ID: <49E68944.3050808@bbs.darktech.org> Hi Trent, Please modify the Javadoc to read that timeouts will return 0. PS: The rxtx source contains plenty of ... questionable ... lines of code. The following items come to mind: 1) In serial_read() we return -1 on various error codes instead of throwing the appropriate exception back into the Java layer. 2) Some Java methods print error messages to stdout instead of throwing exceptions on invalid input. 3) #ifdef LIFE_IS_GOOD (is this ever used?) and "/* Baby did a bad baad thing */". Ifdef and comments like this litter the code. 4) Most files use C-language instead of C++. I am not advocating fancy C++ but rather C code wrapped in objects. Moving variable declarations closer to their usage and perhaps grouping related methods into cohesive classes would improve readability. I know this is an open-source project, but the quality of the code freaks me out :) Is there any resistance to fixing some of these problems? Gili Trent Jarvi wrote: > > Hi Gili, > > I guess the documentation just needs to be clear and consistant (which > it really wasn't before). This is what caught my eye but looking > above it, I see the previous documentation mentions -1 in places too. > > -*timeout threshold Behavior > -*------------------------------------------------------------------------ > > -*0 0 blocks until 1 byte is available > -*>0 0 blocks until timeout occurs, returns 0 on timeout > -*>0 >0 blocks until timeout or reads threshold bytes, > - returns 0 on timeout > -*0 >0 blocks until reads threshold bytes > - */ > + * timeout threshold Behavior > + * > --------------------------------------------------------------------------- > > + * < 0 <= 0 blocks until any data is available. > + * < 0 > 0 blocks until {@code min(threshold, > b.len)} bytes are available. > + * >=0 <=0 blocks for {@code timeout} ms or until > any data is available. Returns -1 on timeout. > + * >=0 > 0 blocks for {@code timeout} ms or until > {@code min(threshold, b.len)} bytes are available. Returns -1 on timeout. > > > > On Wed, 15 Apr 2009, cowwoc wrote: > >> >> Actually returning -1 on timeout would be bug on my part. I >> believe that InputStream is expecting us to return 0 in such a case. >> Which part of my patch changes the return value? >> >> Thanks, >> Gili >> >> Trent Jarvi wrote: >>> On Wed, 15 Apr 2009, cowwoc wrote: >>> >>>> Hi, >>>> >>>> Please review the attached patch. >>>> >>>> - fixes disableReceiveTimeout() so reads now block until data is >>>> available. >>>> - receive timeouts and threshold handling is now more consistent >>>> across all implementations >>>> >>> >>> Hi Gili, >>> >>> This looks good to me. One 'minor' issue is that you are returning >>> -1 instead of 0 now on timeout. It is fair to say timeouts are the >>> same as the end of input but that is new behavior in rxtx we should >>> warn existing users about so they can adjust their code. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >> From cowwoc at bbs.darktech.org Wed Apr 15 19:30:08 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Wed, 15 Apr 2009 21:30:08 -0400 Subject: [Rxtx] Java5 support In-Reply-To: References: <49E631BF.9040501@bbs.darktech.org> <9DA32B4D8579AF44AD96C1CC2E9C518D0346E9EB@MTL-MSG-02.cgiclients.com> Message-ID: <49E68A20.80209@bbs.darktech.org> Trent Jarvi wrote: > The project isn't interested in breaking projects or changing the API. > That said, we do allow some extensions to be added that are clearly marked > as such. These extensions are all in the weird science category - they > are not alternatives to doing what the API can already do or even > something many people would want to use some of the time. We could define rxtx-specific classes in gnu.io that extend those in javax.comm so users would enjoy both backwards compatibility as well as rxtx-specific extensions. > The gnu.io namespace is used to avoid polluting of the javax.comm > namespace. There are a number of reasons why we could be concerned about > using javax.comm including political and/or legal questions but the main > reason is a project like rxtx should do no harm. Did anyone from Sun \take issue with the aforementioned approach (gnu.io extending javax.comm)? Gili > On Wed, 15 Apr 2009, Dyer, Tristan wrote: > >> That's weird. >> >> All I had to do to get my project running on RxTx was to change >> javax.comm to gnu.io >> >> I assume the reason for the fork to gnu.io was precisely to preserve >> compatibility with javax.comm. Unless Sun is willing to give you a TCK >> (or someone wants to pay for it) you wouldn't be able to provide any of >> the "new" javax.comm 3.0 feature set to windows and call it javax.comm, >> and as a side effect you get to keep the api consistent across platforms >> as well. Apache has been in a pissing fight with Sun for a couple years >> about this in regards to Harmony. >> >> As I remember rxtx was a lower level that suns CommAPI jar could talk >> to, to provide javax.comm on linux originally. With sun only providing >> CommAPI for some environments it became necessary to fork. >> >> At least that's how I assume it got here. >> >> Tristan >> >> >> -----Original Message----- >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >> Of cowwoc >> Sent: Wednesday, April 15, 2009 4:13 PM >> To: rxtx at qbang.org >> Subject: Re: [Rxtx] Java5 support >> >>> A recent post reminded me of this old thread that I do not think got >> any >>> replies. >>> >>> Here is my take on the subject (of improving the API): >>> >>> Please do not 'improve' the API! >>> >>> Serial port is an old, simple and mature thing. Let's keep it that >> way. >>> Very little will be gained by 'improving' it. It is already too bad >>> that Sun spoiled the internals of javax.comm in version 3,0 so that >> the >>> gnu.io package had to be coined. That is a nuisance but nothing >> compared to >>> what happens if we start 'improve' the API and make it incompatible >> with >>> Java Comm API. >>> >>> Even additions should be resisted as this will encourage people to >> write >>> code that is not compatible with the 'standard' Java Comm API. The >> world >>> does not need more standards but better compliance to existing >> standards. >>> If someone feels things like generics/iterators for are needed it is >> simple >>> to wrap the rxtx or java comm classes into classes to implement these >>> new language features without changing the API. >>> >>> rxtx us great and many thanks and cudos to the maintainers and >> creators but >>> it is lamentable that something this basic needs to be addressed >> outside >>> standard JRE. Not to mention being able to do basic USB stuff in >> Java/std >>> JRE in cross platform deployable fashion. >>> >>> br Kusti >> Hi Kusti, >> >> I must be missing something... I thought the entire point of forking >> >> off gnu.io was to innovate the API in a different direction than >> javax.comm, otherwise why wouldn't you stick to the standard API? >> >> Thanks, >> Gili >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Apr 15 20:19:01 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 15 Apr 2009 20:19:01 -0600 (MDT) Subject: [Rxtx] Timeout patch In-Reply-To: <49E68944.3050808@bbs.darktech.org> References: <49E64A4A.1050806@bbs.darktech.org> <49E6734E.4010809@bbs.darktech.org> <49E68944.3050808@bbs.darktech.org> Message-ID: Hi Gili, Your glowing review obviously means you have not read termios.c :) I'm not against the type of changes like you suggest. I do think they will need bake time and we have people waiting for what we have now. Putting proactive changes in the following release would be fine. The returning -1 issues are wrong and should be fixed. We can do that now. Regarding C/C++, I think the best thing to do for this project is push as much logic as is possible out of the C files and into Java. Use Java for the objects and C to perform as little as possible. This is a compromise in a sense; C++ is perfectly fine and would work. C++ could even be easier to read and probably would avoid some bugs - especial with C strings. I really don't want to build g++ cross compilers for all the platforms we do in the ToyBox. In practice, adding g++ into the mix is an order of magnitude harder to get working. If we can avoid using C++ completely, there is a measurable advantage in what we can easily deliver. http://rxtx.qbang.org//ToyBox Proof of concept: http://rxtx.qbang.org/ToyBox/2.1-7-build1/Linux/glibc-2.3.5/ On Wed, 15 Apr 2009, cowwoc wrote: > Hi Trent, > > Please modify the Javadoc to read that timeouts will return 0. > > PS: The rxtx source contains plenty of ... questionable ... lines of code. > The following items come to mind: > > 1) In serial_read() we return -1 on various error codes instead of throwing > the appropriate exception back into the Java layer. > 2) Some Java methods print error messages to stdout instead of throwing > exceptions on invalid input. > 3) #ifdef LIFE_IS_GOOD (is this ever used?) and "/* Baby did a bad baad > thing */". Ifdef and comments like this litter the code. > 4) Most files use C-language instead of C++. I am not advocating fancy C++ > but rather C code wrapped in objects. Moving variable declarations closer to > their usage and perhaps grouping related methods into cohesive classes would > improve readability. > > I know this is an open-source project, but the quality of the code > freaks me out :) Is there any resistance to fixing some of these problems? > > Gili > > Trent Jarvi wrote: >> >> Hi Gili, >> >> I guess the documentation just needs to be clear and consistant (which it >> really wasn't before). This is what caught my eye but looking above it, I >> see the previous documentation mentions -1 in places too. >> >> -*timeout threshold Behavior >> -*------------------------------------------------------------------------ >> -*0 0 blocks until 1 byte is available >> -*>0 0 blocks until timeout occurs, returns 0 on timeout >> -*>0 >0 blocks until timeout or reads threshold bytes, >> - returns 0 on timeout >> -*0 >0 blocks until reads threshold bytes >> - */ >> + * timeout threshold Behavior >> + * >> --------------------------------------------------------------------------- >> + * < 0 <= 0 blocks until any data is available. >> + * < 0 > 0 blocks until {@code min(threshold, b.len)} >> bytes are available. >> + * >=0 <=0 blocks for {@code timeout} ms or until any >> data is available. Returns -1 on timeout. >> + * >=0 > 0 blocks for {@code timeout} ms or until {@code >> min(threshold, b.len)} bytes are available. Returns -1 on timeout. >> >> >> >> On Wed, 15 Apr 2009, cowwoc wrote: >> >>> >>> Actually returning -1 on timeout would be bug on my part. I believe >>> that InputStream is expecting us to return 0 in such a case. Which part of >>> my patch changes the return value? >>> >>> Thanks, >>> Gili >>> >>> Trent Jarvi wrote: >>>> On Wed, 15 Apr 2009, cowwoc wrote: >>>> >>>>> Hi, >>>>> >>>>> Please review the attached patch. >>>>> >>>>> - fixes disableReceiveTimeout() so reads now block until data is >>>>> available. >>>>> - receive timeouts and threshold handling is now more consistent across >>>>> all implementations >>>>> >>>> >>>> Hi Gili, >>>> >>>> This looks good to me. One 'minor' issue is that you are returning -1 >>>> instead of 0 now on timeout. It is fair to say timeouts are the same as >>>> the end of input but that is new behavior in rxtx we should warn existing >>>> users about so they can adjust their code. >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> >>> > From tjarvi at qbang.org Wed Apr 15 21:38:29 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 15 Apr 2009 21:38:29 -0600 (MDT) Subject: [Rxtx] Java5 support In-Reply-To: <49E68A20.80209@bbs.darktech.org> References: <49E631BF.9040501@bbs.darktech.org> <9DA32B4D8579AF44AD96C1CC2E9C518D0346E9EB@MTL-MSG-02.cgiclients.com> <49E68A20.80209@bbs.darktech.org> Message-ID: On Wed, 15 Apr 2009, cowwoc wrote: > Trent Jarvi wrote: >> The project isn't interested in breaking projects or changing the API. That >> said, we do allow some extensions to be added that are clearly marked as >> such. These extensions are all in the weird science category - they are >> not alternatives to doing what the API can already do or even something >> many people would want to use some of the time. > > We could define rxtx-specific classes in gnu.io that extend those in > javax.comm so users would enjoy both backwards compatibility as well as > rxtx-specific extensions. > >> The gnu.io namespace is used to avoid polluting of the javax.comm >> namespace. There are a number of reasons why we could be concerned about >> using javax.comm including political and/or legal questions but the main >> reason is a project like rxtx should do no harm. > > Did anyone from Sun \take issue with the aforementioned approach > (gnu.io extending javax.comm)? > It would take more than an opinion from someone at Sun before we moved like that. javax.comm (a namespace grandfathered into the JSR) is a broken namespace with a special 'generic' legacy release that may be discontinued at any time. The people using rxtx are interested in what javax.comm was in version 2.0. Not the 3.0 currently offered which appears to be a quick fix for a business need Sun satisfied on Solaris. Why would we ever depend upon (extend) this namespace? -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Wed Apr 1 22:05:13 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Thu, 02 Apr 2009 00:05:13 -0400 Subject: [Rxtx] Windows 64-bit support? Message-ID: <49D43979.4050702@bbs.darktech.org> Hi, I'd like to run RXTX under the Windows 64-bit JVM. Are there plans to release an official 64-bit version anytime soon? Gili From bill7007 at gmail.com Thu Apr 2 16:01:17 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Thu, 2 Apr 2009 18:01:17 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel Message-ID: Hi, I have an rxtx serial application that used to work reliably until I had to move it to newer hardware and kernel. Now, the application sometimes hangs near first port use. When it does hang, it can be released by starting a second copy of the application which is locked out of the ports but does release the first process. Upgraded from rxtx-2.1-7-r2 to rxtx-2.2pre2 but still hangs. Tried to rebuild on the target machine and ran into the 'UTS_RELEASE' undeclared problem so holding on that approach. Recompiled OK on a 2.6.9-42.0.3.ELsmp system. Debug messages were turned on using: "./configure --enable-DEBUG" and modified RXTXPort.java with: "debug = true;" "z = new Zystem(Zystem.PRINT_MODE);" Below is capture of the application with debugging enabled. It show the application hang point, and the second application's printout at the release point. (pre3 is the locally modified version of pre2) Any suggestions on how to pin this down further? Thanks, +BillJ $ java -version java version "1.5.0_06" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05) Java HotSpot(TM) Client VM (build 1.5.0_06-b05, mixed mode, sharing) $ uname -a Linux qms4 2.6.18-92.1.6.el5 #1 SMP Wed Jun 25 13:49:24 EDT 2008 i686 i686 i386 GNU/Linux ***CAPTURE: [qms at qms4 ~]$ ./qms/ScriptFiles/startup.sh Thu Apr 02 13:35:45 EDT 2009:Setting Log File to:/home/qms/qms/QMS.log Thu Apr 02 13:35:45 EDT 2009:TSettings.HandleIni:ReUsing Ini file:/home/qms/qms/qms.properties WARNING: RXTX Version mismatch Jar version = RXTX-2.2pre2 native lib Version = RXTX-2.2pre3 fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB2 fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB1 fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB0 fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile RXTXPort {} RXTX WARNING: This library was compiled to run with OS release 2.4.20 and you are currently running OS release 2.6.18-92.1.6.el5. In some cases this can be a problem. Try recompiling RXTX if you notice strange behavior. If you just compiled RXTX make sure /usr/include/linux is a symbolic link to the include files that came with the kernel source and not an older copy. press enter to continue RXTXPort:RXTXPort(/dev/ttyUSB2) called fhs_lock: creating lockfile: 10127 open: locking worked for /dev/ttyUSB2 open: fd returned is 8 RXTXPort:MontitorThread:MonitorThread() RXTXPort:MontitorThread:run() has_line_status_register_acess: Port does not support TIOCSERGETLSR init_threads: get eis init_threads: set eis init_threads: stop RXTXPort:RXTXPort(/dev/ttyUSB2) returns with fd = 8 RXTXPort:setSerialPortParams(38400 8 1 0) called RXTXPort:setSerialPortParams(38400 8 1 0) returning RXTXPort:getInputStream() called and returning Thu Apr 02 13:36:02 EDT 2009:TSerial[22]:Using Port:/dev/ttyUSB2 RXTXPort:getOutputStream() called and returning Thu Apr 02 13:36:02 EDT 2009:TSerial[22].Transmit:TN Entering RXTXPort:SerialOutputStream:write(4) writeArray() Leaving RXTXPort:SerialOutputStream:write(4) RXTXPort:SerialOutputStream:flush() enter RXTXPort:SerialOutputStream:flush() leave Thu Apr 02 13:36:02 EDT 2009:TSerial[22].Transmit:RV Entering RXTXPort:SerialOutputStream:write(4) writeArray() Leaving RXTXPort:SerialOutputStream:write(4) RXTXPort:SerialOutputStream:flush() enter RXTXPort:SerialInputStream:read(8192 0 8192) called ***FIRST PROCESS HANGS HERE ***THEN PROCEEDS AFTER SECOND PROCESS STARTS RXTXPort:SerialOutputStream:flush() leave Thu Apr 02 13:41:29 EDT 2009:TSerial[22].Transmit:IH9 Entering RXTXPort:SerialOutputStream:write(5) writeArray() Leaving RXTXPort:SerialOutputStream:write(5) RXTXPort:SerialOutputStream:flush() enter RXTXPort:SerialOutputStream:flush() leave Thu Apr 02 13:41:29 EDT 2009:TSerial[22].Transmit:IL11 ***END CAPTURE ***CAPTURE SECOND PROCESS FAILS OPEN [qms at qms4 ~]$ ./qms/ScriptFiles/startup.sh Thu Apr 02 13:41:27 EDT 2009:Setting Log File to:/home/qms/qms/QMS.log Thu Apr 02 13:41:27 EDT 2009:TSettings.HandleIni:ReUsing Ini file:/home/qms/qms/qms.properties WARNING: RXTX Version mismatch Jar version = RXTX-2.2pre2 native lib Version = RXTX-2.2pre3 fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB2: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB1: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB0: File exists fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB2: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB1: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB0: File exists fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile Thu Apr 02 13:41:30 EDT 2009:TIOBoard: java.io.IOException: java.io.IOException: TSerial[22]: Open Failed ***END CAPTURE -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090402/c66f8d70/attachment-0015.html From netbeans at gatworks.com Thu Apr 2 17:15:04 2009 From: netbeans at gatworks.com (U. George) Date: Thu, 02 Apr 2009 19:15:04 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: Message-ID: <49D546F8.20807@gatworks.com> > "z = new Zystem(Zystem.PRINT_MODE);" > Below is capture of the application with debugging enabled. It show > the application hang point, and the second application's printout at the > release point. (pre3 is the locally modified version of pre2) > Any suggestions on how to pin this down further? > Thanks, > +BillJ When perceived runability is hung, try a ^\ ( control \) on console. This gets the JVM to dump the stacks of all the java threads. If you know the thread that is stuck, then u can see what java statement its stuck at. From tjarvi at qbang.org Thu Apr 2 19:25:17 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 2 Apr 2009 19:25:17 -0600 (MDT) Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: <49D546F8.20807@gatworks.com> References: <49D546F8.20807@gatworks.com> Message-ID: On Thu, 2 Apr 2009, U. George wrote: >> "z = new Zystem(Zystem.PRINT_MODE);" >> Below is capture of the application with debugging enabled. It show >> the application hang point, and the second application's printout at the >> release point. (pre3 is the locally modified version of pre2) >> Any suggestions on how to pin this down further? >> Thanks, >> +BillJ > > When perceived runability is hung, try a ^\ ( control \) on console. > This gets the JVM to dump the stacks of all the java threads. > If you know the thread that is stuck, then u can see what java statement > its stuck at. I've also noticed some linux systems hanging with open/read/write and saw kacpid storms. I need to look at it more but did observe kacpid consuming a core and not returning to a normal state for a significant period of time. It was easy to observe from top sorted by CPU usage. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Apr 2 19:26:18 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 2 Apr 2009 19:26:18 -0600 (MDT) Subject: [Rxtx] Windows 64-bit support? In-Reply-To: <49D43979.4050702@bbs.darktech.org> References: <49D43979.4050702@bbs.darktech.org> Message-ID: On Thu, 2 Apr 2009, cowwoc wrote: > Hi, > > I'd like to run RXTX under the Windows 64-bit JVM. Are there plans > to release an official 64-bit version anytime soon? > It is in the prerelease and will be in the final release. I'm pushing it through as fast as I can in my free time. -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Thu Apr 2 22:57:34 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Fri, 03 Apr 2009 00:57:34 -0400 Subject: [Rxtx] Missing documentation In-Reply-To: References: <49D43979.4050702@bbs.darktech.org> Message-ID: <49D5973E.4050400@bbs.darktech.org> Hi, I noticed that RXTX 2.1 drops javax.comm support in favor of gnu.io. I have one major problem with this: the gui.io.* documentation is very poor. Many classes and methods have no Javadoc at all which makes them difficult to use. Please fix this for the final release. Thank you, Gili From alex.sas at freemail.hu Fri Apr 3 01:36:54 2009 From: alex.sas at freemail.hu (Sas Alex) Date: Fri, 3 Apr 2009 09:36:54 +0200 (CEST) Subject: [Rxtx] Serial port false reads Message-ID: Hi all, On Windows XP, using rxtx-2.1-7-r2 I have a program communicating on a serial line like the following (excerpt): { os.write(command); os.flush(); // Thread.sleep(period); // read response while(is.available() > 0) { is.read() } } If there is a sleep between the os.flush and the reading cycle the correct answer is received. Otherwise (sometimes) there are extra, erronous characters at the beginning of the answer, but the correct answer (according to the protocol) also arrives, afterwards. Is this a normal behaviour, one should wait before the read? If yes, is there a way to determine the minimum amount of time to wait for? Serial port params are: 9600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE. Thank you in advance, Alex ________________________________________________________ El?foglal?si akci? meghosszabb?tva! Korfui ?d?l?s m?r 56.910 Ft-t?l. http://www.budavartours.hu/gorogorszag/?utm_campaign=origo&utm_source=freemail_kimeno_090403&utm_medium=ct&utm_content=korfu_elofoglalasi_akcio#reg_Korfu -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090403/8f3650ea/attachment-0015.html From bill7007 at gmail.com Fri Apr 3 16:15:30 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Fri, 3 Apr 2009 18:15:30 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: <49D546F8.20807@gatworks.com> Message-ID: > When perceived runability is hung, try a ^\ ( control \) on console. >> This gets the JVM to dump the stacks of all the java threads. > > Good idea... A thread dump is below, it looks like only some system threads are in wait state which is probably normal. The "main" thread is stopped writing the first data out the serial port which should complete but its has stopped at: at gnu.io.RXTXPort.nativeDrain(Native Method) It show its state as runnable though. There is another thread, "SerialReader_22", that is waiting to read any data on the same port. I'll bring the app up under Netbeans debugger next. >> > I've also noticed some linux systems hanging with open/read/write and saw > kacpid storms. No CPU use going when it hangs, acts like a deadlock. THREAD DUMP AT HANG: Entering RXTXPort:SerialOutputStream:write(4) writeArray() Leaving RXTXPort:SerialOutputStream:write(4) RXTXPort:SerialOutputStream:flush() enter RXTXPort:SerialInputStream:read(8192 0 8192) called Full thread dump Java HotSpot(TM) Client VM (1.5.0_06-b05 mixed mode, sharing): "SerialReader_22" daemon prio=1 tid=0x087abf38 nid=0x3c8b runnable [0xb1a43000..0xb1a43f30] at gnu.io.RXTXPort.readArray(Native Method) at gnu.io.RXTXPort$SerialInputStream.read(RXTXPort.java:1454) - locked <0x88ca55b8> (a gnu.io.RXTXPort$SerialInputStream) at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:411) at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) - locked <0x88cab378> (a java.io.InputStreamReader) at java.io.InputStreamReader.read(InputStreamReader.java:167) at java.io.BufferedReader.fill(BufferedReader.java:136) at java.io.BufferedReader.readLine(BufferedReader.java:299) - locked <0x88cab378> (a java.io.InputStreamReader) at java.io.BufferedReader.readLine(BufferedReader.java:362) at qms.TSerialPort$SerialRead.run(TSerialPort.java:268) at java.lang.Thread.run(Thread.java:595) "Thread-1" prio=1 tid=0x08a43360 nid=0x3c8a runnable [0xb1ac4000..0xb1ac4db0] at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1641) "AWT-XAWT" daemon prio=1 tid=0x08acc848 nid=0x3c87 runnable [0xb1b45000..0xb1b45e30] at sun.awt.X11.XToolkit.waitForEvents(Native Method) at sun.awt.X11.XToolkit.run(XToolkit.java:463) at sun.awt.X11.XToolkit.run(XToolkit.java:438) at java.lang.Thread.run(Thread.java:595) "Java2D Disposer" daemon prio=1 tid=0x08ab9d30 nid=0x3c86 in Object.wait() [0xb1bc6000..0xb1bc70b0] at java.lang.Object.wait(Native Method) - waiting on <0x8917b110> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:116) - locked <0x8917b110> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:132) at sun.java2d.Disposer.run(Disposer.java:107) at java.lang.Thread.run(Thread.java:595) "Low Memory Detector" daemon prio=1 tid=0x087bea68 nid=0x3c84 runnable [0x00000000..0x00000000] "CompilerThread0" daemon prio=1 tid=0x087bd4c0 nid=0x3c83 waiting on condition [0x00000000..0xb23a7a18] "Signal Dispatcher" daemon prio=1 tid=0x087bc520 nid=0x3c82 runnable [0x00000000..0x00000000] "Finalizer" daemon prio=1 tid=0x087b5710 nid=0x3c81 in Object.wait() [0xb26a9000..0xb26a9f30] at java.lang.Object.wait(Native Method) - waiting on <0x8914a770> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:116) - locked <0x8914a770> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:132) at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159) "Reference Handler" daemon prio=1 tid=0x087b49c8 nid=0x3c80 in Object.wait() [0xb272a000..0xb272adb0] at java.lang.Object.wait(Native Method) - waiting on <0x8914a7f0> (a java.lang.ref.Reference$Lock) at java.lang.Object.wait(Object.java:474) at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116) - locked <0x8914a7f0> (a java.lang.ref.Reference$Lock) "main" prio=1 tid=0x08777b88 nid=0x3c7e runnable [0xbffa7000..0xbffa74f8] at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1248) at qms.TSerialPort.Transmit(TSerialPort.java:192) - locked <0x88c99a68> (a qms.TSerialPort) at qms.TIOBoard.GetIOBoardVersion(TIOBoard.java:168) at qms.TIOBoard.(TIOBoard.java:73) at qms.TQMS.(TQMS.java:47) at qms.MainForm.(MainForm.java:2076) at qms.MainForm.main(MainForm.java:2099) "VM Thread" prio=1 tid=0x087b1e20 nid=0x3c7f runnable "VM Periodic Task Thread" prio=1 tid=0x087bff50 nid=0x3c85 waiting on condition -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090403/20b7bca4/attachment-0014.html From Martin.Oberhuber at windriver.com Fri Apr 3 16:23:43 2009 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Sat, 4 Apr 2009 00:23:43 +0200 Subject: [Rxtx] Missing documentation In-Reply-To: <49D5973E.4050400@bbs.darktech.org> References: <49D43979.4050702@bbs.darktech.org> <49D5973E.4050400@bbs.darktech.org> Message-ID: <460801A4097E3D4CA04CC64EE648584809C8BD6F@ism-mail03.corp.ad.wrs.com> Hello Gili, The classes in the gnu.io namespace are designed to work exactly as their counterparts in the javax.comm namespace. Therefore, if you just take the javax.comm Javadocs that's what you want. Unfortunately I don't think we can just copy & paste the javax.comm Javadocs into RXTX due to license restrictions. I guess that's the main reason why RXTX is not (yet) Javadoc'd as extensively as it should be. Actually, writing Javadocs from scratch WITHOUT referencing the wording of the Sun Javadocs is not that easy. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of cowwoc > Sent: Freitag, 03. April 2009 06:58 > To: rxtx at qbang.org > Subject: [Rxtx] Missing documentation > > Hi, > > I noticed that RXTX 2.1 drops javax.comm support in favor > of gnu.io. > I have one major problem with this: the gui.io.* > documentation is very > poor. Many classes and methods have no Javadoc at all which > makes them > difficult to use. Please fix this for the final release. > > Thank you, > Gili > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Fri Apr 3 16:54:50 2009 From: netbeans at gatworks.com (U. George) Date: Fri, 03 Apr 2009 18:54:50 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: <49D546F8.20807@gatworks.com> Message-ID: <49D693BA.8060909@gatworks.com> I would have tried 2 or 3 "^\" . If things are stuck, then all will be at same 'java' instruction. If thread is moving, then one of the snapshots would be different. I *think* flushing/draining wont return until the kernel buffers to device have been accepted by device. Stuck/paused device? Bill Johnson wrote: > > > > > When perceived runability is hung, try a ^\ ( control \) on console. > This gets the JVM to dump the stacks of all the java threads. > > > Good idea... A thread dump is below, it looks like only some system > threads are in wait state which is prob From cowwoc at bbs.darktech.org Fri Apr 3 17:45:09 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Fri, 03 Apr 2009 19:45:09 -0400 Subject: [Rxtx] Missing documentation In-Reply-To: <460801A4097E3D4CA04CC64EE648584809C8BD6F@ism-mail03.corp.ad.wrs.com> References: <49D43979.4050702@bbs.darktech.org> <49D5973E.4050400@bbs.darktech.org> <460801A4097E3D4CA04CC64EE648584809C8BD6F@ism-mail03.corp.ad.wrs.com> Message-ID: <49D69F85.3030804@bbs.darktech.org> You could always send Sun a formal email and ask for permission to copy their Javadoc. I doubt they would give you problems. Gili Oberhuber, Martin wrote: > Hello Gili, > > The classes in the gnu.io namespace are designed to work exactly > as their counterparts in the javax.comm namespace. Therefore, > if you just take the javax.comm Javadocs that's what you want. > > Unfortunately I don't think we can just copy & paste the > javax.comm Javadocs into RXTX due to license restrictions. > > I guess that's the main reason why RXTX is not (yet) Javadoc'd > as extensively as it should be. Actually, writing Javadocs > from scratch WITHOUT referencing the wording of the Sun > Javadocs is not that easy. > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] >> On Behalf Of cowwoc >> Sent: Freitag, 03. April 2009 06:58 >> To: rxtx at qbang.org >> Subject: [Rxtx] Missing documentation >> >> Hi, >> >> I noticed that RXTX 2.1 drops javax.comm support in favor >> of gnu.io. >> I have one major problem with this: the gui.io.* >> documentation is very >> poor. Many classes and methods have no Javadoc at all which >> makes them >> difficult to use. Please fix this for the final release. >> >> Thank you, >> Gili >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> From cowwoc at bbs.darktech.org Sat Apr 4 15:13:38 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sat, 04 Apr 2009 17:13:38 -0400 Subject: [Rxtx] Java5 support Message-ID: <49D7CD82.1040904@bbs.darktech.org> Now that you dropped javax.comm support, how about improving the API by replacing Enumation by Iterator, int by enum, and using Generics? It would improve the usability of the API. Gili From cowwoc at bbs.darktech.org Sat Apr 4 16:12:13 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sat, 04 Apr 2009 18:12:13 -0400 Subject: [Rxtx] RXTX Version mismatch in 2.2pre2 Message-ID: <49D7DB3D.5040008@bbs.darktech.org> When using RXTX-2.2pre2 I always get the following message: WARNING: RXTX Version mismatch Jar version = RXTX-2.2pre1 native lib Version = RXTX-2.2pre2 I have double checked that I am using the correct Jar file. Is this a known bug in pre2? Gili From tjarvi at qbang.org Sat Apr 4 16:48:53 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Apr 2009 16:48:53 -0600 (MDT) Subject: [Rxtx] RXTX Version mismatch in 2.2pre2 In-Reply-To: <49D7DB3D.5040008@bbs.darktech.org> References: <49D7DB3D.5040008@bbs.darktech.org> Message-ID: > When using RXTX-2.2pre2 I always get the following message: > > WARNING: RXTX Version mismatch > Jar version = RXTX-2.2pre1 > native lib Version = RXTX-2.2pre2 > Yep. You should still be able to test it. -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Sat Apr 4 16:50:43 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sat, 04 Apr 2009 18:50:43 -0400 Subject: [Rxtx] RXTX Version mismatch in 2.2pre2 In-Reply-To: References: <49D7DB3D.5040008@bbs.darktech.org> Message-ID: <49D7E443.9070404@bbs.darktech.org> In other words this is a known bug that will be fixed in the final version? Gili Trent Jarvi wrote: > > >> When using RXTX-2.2pre2 I always get the following message: >> >> WARNING: RXTX Version mismatch >> Jar version = RXTX-2.2pre1 >> native lib Version = RXTX-2.2pre2 >> > > Yep. > > You should still be able to test it. > > -- > Trent Jarvi > tjarvi at qbang.org From cowwoc at bbs.darktech.org Sat Apr 4 16:57:34 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sat, 04 Apr 2009 18:57:34 -0400 Subject: [Rxtx] IOException: Underlying input stream returned zero bytes Message-ID: <49D7E5DE.2050405@bbs.darktech.org> Hi, There seems to be a bug in RXTX 2.2pre2's handling of InputStream timeouts. If you open a serial port without ever invoking enableReceiveTimeout() then invoking InputStream.read() will always return 0 bytes right away. If you wrap the InputStream and invoke BufferedReader.readline() you will get the following exception: java.io.IOException: Underlying input stream returned zero bytes at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:268) [na:1.6.0_14-ea] at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:306) [na:1.6.0_14-ea] at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:158) [na:1.6.0_14-ea] at java.io.InputStreamReader.read(InputStreamReader.java:167) [na:1.6.0_14-ea] at java.io.BufferedReader.fill(BufferedReader.java:136) [na:1.6.0_14-ea] at java.io.BufferedReader.readLine(BufferedReader.java:299) [na:1.6.0_14-ea] at java.io.BufferedReader.readLine(BufferedReader.java:362) [na:1.6.0_14-ea] [snip] If you enable a timeout, the exception will only occur after the timeout expires. In short, it looks like RXTX is using a default timeout of zero (I am expecting it to block forever). It looks like other people have run into this as well: http://forums.sun.com/thread.jspa?threadID=5165346&start=10&tstart=0 Please confirm whether this is a known bug. Thank you, Gili From tjarvi at qbang.org Sat Apr 4 17:27:19 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Apr 2009 17:27:19 -0600 (MDT) Subject: [Rxtx] IOException: Underlying input stream returned zero bytes In-Reply-To: <49D7E5DE.2050405@bbs.darktech.org> References: <49D7E5DE.2050405@bbs.darktech.org> Message-ID: On Sat, 4 Apr 2009, cowwoc wrote: > Hi, > > There seems to be a bug in RXTX 2.2pre2's handling of InputStream > timeouts. If you open a serial port without ever invoking > enableReceiveTimeout() then invoking InputStream.read() will always > return 0 bytes right away. If you wrap the InputStream and invoke > BufferedReader.readline() you will get the following exception: > > java.io.IOException: Underlying input stream returned zero bytes > at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:268) > [na:1.6.0_14-ea] > at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:306) > [na:1.6.0_14-ea] > at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:158) > [na:1.6.0_14-ea] > at java.io.InputStreamReader.read(InputStreamReader.java:167) > [na:1.6.0_14-ea] > at java.io.BufferedReader.fill(BufferedReader.java:136) > [na:1.6.0_14-ea] > at java.io.BufferedReader.readLine(BufferedReader.java:299) > [na:1.6.0_14-ea] > at java.io.BufferedReader.readLine(BufferedReader.java:362) > [na:1.6.0_14-ea] > [snip] > > If you enable a timeout, the exception will only occur after the > timeout expires. In short, it looks like RXTX is using a default timeout > of zero (I am expecting it to block forever). It looks like other people > have run into this as well: > http://forums.sun.com/thread.jspa?threadID=5165346&start=10&tstart=0 > > Please confirm whether this is a known bug. > Hi Gili I've known about it but was not sure if it was a bug or not. It looks like we can treat it as a bug if nio is throwing an exception. Timeout and Thresholds are well documented in javax.comm but I didn't recall seeing defaults. For that reason, I've encouraged people to set the threshold and timeout to what they expect. Another note about InputStream.read(void): I noticed that I don't use that function at all while looking at code coverage results. Keep your eye out for additional issues. -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Sat Apr 4 19:03:29 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sat, 04 Apr 2009 21:03:29 -0400 Subject: [Rxtx] IOException: Underlying input stream returned zero bytes In-Reply-To: References: <49D7E5DE.2050405@bbs.darktech.org> Message-ID: <49D80361.7020801@bbs.darktech.org> Trent Jarvi wrote: > For that reason, I've encouraged people to set the threshold and timeout > to what they expect. It doesn't help. There doesn't seem to be a way to disable the timeout, even if you invoke disableReceiveTimeout() explicitly. Let me know when you put in a fix and I will test it. Thanks, Gili From cowwoc at bbs.darktech.org Sat Apr 4 23:27:25 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 01:27:25 -0400 Subject: [Rxtx] Crash in termios.c:892 Message-ID: <49D8413D.7040105@bbs.darktech.org> I can reproduce a crash in RXTX 2.2 pre2 100% of the time using my application code, but I can't seem to bring it down to a minimal testcase. Here is what I see: - thread begins running - open com1 - close com1 - open com5 - leave com5 open - thread shuts down - repeat the same process in a new thread - crash occurs when trying to open com1. Crash disappears if I close() com5 in the previous thread. The output window contains the following: # # A fatal error has been detected by the Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x05475cf6, pid=6064, tid=5436 # # JRE version: 6.0_14-b04 # Java VM: Java HotSpot(TM) Client VM (14.0-b13 mixed mode, sharing windows-x86 ) # Problematic frame: # C [rxtxSerial.dll+0x5cf6] # # An error report file with more information is saved as: # C:\Users\Gili\Documents\foobar\source\hs_err_pid6064.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp Error 0x5 at ..\src\termios.c(892): Access is denied. # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # Please let me know if the crash dump is enough to track down this bug. Thank you, Gili -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: hs_err_pid6064.log Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20090405/7133a1ce/attachment-0011.pl From cowwoc at bbs.darktech.org Sun Apr 5 00:24:19 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 02:24:19 -0400 Subject: [Rxtx] SerialPort.getName() is wrong Message-ID: <49D84E93.7050606@bbs.darktech.org> Sorry for all these emails but I keep on running into more issues. Here is what I noticed: - CommPortIdentifier.getPortIdentifier("COM5") returns a CommPortIdentifier where getName() == "COM5" - If, however, you invoke CommPortIdentifier.open() you get back a SerialPort where SerialPort.getName() is "//./COM5" I am expecting the name to remain consistent. "//./COM5" looks like an implementation detail and (as far as I can tell) it can't be used as an argument for any API method so it is somewhat useless. If getName() were to return "COM5" I could at least use it to get back the original CommPortIdentifier or compare against "known names" such as "COMx" or "LPTx". What do you think? Gili From tjarvi at qbang.org Sun Apr 5 10:18:42 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Apr 2009 10:18:42 -0600 (MDT) Subject: [Rxtx] SerialPort.getName() is wrong In-Reply-To: <49D84E93.7050606@bbs.darktech.org> References: <49D84E93.7050606@bbs.darktech.org> Message-ID: On Sun, 5 Apr 2009, cowwoc wrote: > > Sorry for all these emails but I keep on running into more issues. > Here is what I noticed: > > - CommPortIdentifier.getPortIdentifier("COM5") returns a > CommPortIdentifier where getName() == "COM5" > - If, however, you invoke CommPortIdentifier.open() you get back a > SerialPort where SerialPort.getName() is "//./COM5" > > I am expecting the name to remain consistent. "//./COM5" looks like > an implementation detail and (as far as I can tell) it can't be used as > an argument for any API method so it is somewhat useless. If getName() > were to return "COM5" I could at least use it to get back the original > CommPortIdentifier or compare against "known names" such as "COMx" or > "LPTx". What do you think? > Sure. If it itches enough you should be able to fix this in RXTXCommDriver.java. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Apr 5 10:27:58 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Apr 2009 10:27:58 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D8413D.7040105@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> Message-ID: On Sun, 5 Apr 2009, cowwoc wrote: > > I can reproduce a crash in RXTX 2.2 pre2 100% of the time using my > application code, but I can't seem to bring it down to a minimal testcase. > Here is what I see: > > - thread begins running > - open com1 > - close com1 > - open com5 > - leave com5 open > - thread shuts down > - repeat the same process in a new thread > - crash occurs when trying to open com1. Crash disappears if I close() com5 > in the previous thread. > > The output window contains the following: > > # > # A fatal error has been detected by the Java Runtime Environment: > # > # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x05475cf6, pid=6064, > tid=5436 > # > # JRE version: 6.0_14-b04 > # Java VM: Java HotSpot(TM) Client VM (14.0-b13 mixed mode, sharing > windows-x86 ) > # Problematic frame: > # C [rxtxSerial.dll+0x5cf6] > # > # An error report file with more information is saved as: > # C:\Users\Gili\Documents\foobar\source\hs_err_pid6064.log > # > # If you would like to submit a bug report, please visit: > # http://java.sun.com/webapps/bugreport/crash.jsp > Error 0x5 at ..\src\termios.c(892): Access is denied. > > > # The crash happened outside the Java Virtual Machine in native code. > # See problematic frame for where to report the bug. > # > > Please let me know if the crash dump is enough to track down this bug. > Hi Gili, You are responsible for cleaning up the serial ports when using threads. That said, if the thread did shut down, finalize should have been called if you are not passing the object around. See RXTXPort.java. protected void finalize() { if (debug) z.reportln( "RXTXPort:finalize()"); if( fd > 0 ) { if (debug) z.reportln( "RXTXPort:calling close()"); close(); } z.finalize(); } The exception is interesting. This is on Vista? Usually it just gives an open error when another process has the port. -- Trent Jarvi tjarvi at mathworks.com From cowwoc at bbs.darktech.org Sun Apr 5 10:35:55 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 12:35:55 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: References: <49D8413D.7040105@bbs.darktech.org> Message-ID: <49D8DDEB.5010908@bbs.darktech.org> Trent Jarvi wrote: > You are responsible for cleaning up the serial ports when using threads. > That said, if the thread did shut down, finalize should have been called > if you are not passing the object around. See RXTXPort.java. > > protected void finalize() > { > if (debug) > z.reportln( "RXTXPort:finalize()"); > if( fd > 0 ) > { > if (debug) > z.reportln( "RXTXPort:calling close()"); > close(); > } > z.finalize(); > } Two points: 1) One should never rely on finalizers because they may never run. 2) RXTX shouldn't cause the entire JVM to crash if I misuse the API. The native code should recover more gracefully. > The exception is interesting. This is on Vista? Usually it just gives > an open error when another process has the port. Yes, this is on Vista 64-bit. I'd really like to see this bug fixed. Is this code compilable under Visual Studio? If so, I can debug the problem on my end and send you a patch. Thanks, Gili From cowwoc at bbs.darktech.org Sun Apr 5 10:36:20 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 12:36:20 -0400 Subject: [Rxtx] SerialPort.getName() is wrong In-Reply-To: References: <49D84E93.7050606@bbs.darktech.org> Message-ID: <49D8DE04.6030306@bbs.darktech.org> Trent Jarvi wrote: >> I am expecting the name to remain consistent. "//./COM5" looks like >> an implementation detail and (as far as I can tell) it can't be used as >> an argument for any API method so it is somewhat useless. If getName() >> were to return "COM5" I could at least use it to get back the original >> CommPortIdentifier or compare against "known names" such as "COMx" or >> "LPTx". What do you think? >> > > Sure. > > If it itches enough you should be able to fix this in RXTXCommDriver.java. I'm not sure I understand. Are you saying that if I submit a patch you will commit it? Gili From tjarvi at qbang.org Sun Apr 5 10:46:23 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Apr 2009 10:46:23 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D8DDEB.5010908@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> Message-ID: On Sun, 5 Apr 2009, cowwoc wrote: > Trent Jarvi wrote: >> You are responsible for cleaning up the serial ports when using threads. >> That said, if the thread did shut down, finalize should have been called if >> you are not passing the object around. See RXTXPort.java. >> >> protected void finalize() >> { >> if (debug) >> z.reportln( "RXTXPort:finalize()"); >> if( fd > 0 ) >> { >> if (debug) >> z.reportln( "RXTXPort:calling close()"); >> close(); >> } >> z.finalize(); >> } > > Two points: > > 1) One should never rely on finalizers because they may never run. > 2) RXTX shouldn't cause the entire JVM to crash if I misuse the API. The > native code should recover more gracefully. > >> The exception is interesting. This is on Vista? Usually it just gives an >> open error when another process has the port. > > Yes, this is on Vista 64-bit. I'd really like to see this bug fixed. > Is this code compilable under Visual Studio? If so, I can debug the problem > on my end and send you a patch. > It will compile with the msvc cl.exe and nmake. See Makefile.msvc in the top level directory. You will need to adjust the JAVA_HOME variable. Also use the MSVC command prompt for x86_64 so cl and nmake are on your path. All the best, -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Apr 5 10:49:10 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Apr 2009 10:49:10 -0600 (MDT) Subject: [Rxtx] SerialPort.getName() is wrong In-Reply-To: <49D8DE04.6030306@bbs.darktech.org> References: <49D84E93.7050606@bbs.darktech.org> <49D8DE04.6030306@bbs.darktech.org> Message-ID: On Sun, 5 Apr 2009, cowwoc wrote: > Trent Jarvi wrote: >>> I am expecting the name to remain consistent. "//./COM5" looks like >>> an implementation detail and (as far as I can tell) it can't be used as >>> an argument for any API method so it is somewhat useless. If getName() >>> were to return "COM5" I could at least use it to get back the original >>> CommPortIdentifier or compare against "known names" such as "COMx" or >>> "LPTx". What do you think? >>> >> >> Sure. >> >> If it itches enough you should be able to fix this in RXTXCommDriver.java. > > I'm not sure I understand. Are you saying that if I submit a patch > you will commit it? > Hi Gili, Post a patch here and if nobody complains, we will commit it and give you credit. Yep. Other issues like changing the API to use java5 that may break existing apps are likely to run into objections but bug fixes usually get fixed just as you mention. -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Sun Apr 5 10:55:07 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 12:55:07 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> Message-ID: <49D8E26B.2040705@bbs.darktech.org> Trent Jarvi wrote: > It will compile with the msvc cl.exe and nmake. See Makefile.msvc in > the top level directory. You will need to adjust the JAVA_HOME > variable. Also use the MSVC command prompt for x86_64 so cl and nmake > are on your path. This is very odd. The CVS version of the code does not contain this file. Do you keep the latest code somewhere else? Gili From cowwoc at bbs.darktech.org Sun Apr 5 11:01:58 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 13:01:58 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D8E26B.2040705@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> Message-ID: <49D8E406.10708@bbs.darktech.org> cowwoc wrote: > Trent Jarvi wrote: >> It will compile with the msvc cl.exe and nmake. See Makefile.msvc in >> the top level directory. You will need to adjust the JAVA_HOME >> variable. Also use the MSVC command prompt for x86_64 so cl and nmake >> are on your path. > > This is very odd. The CVS version of the code does not contain this > file. Do you keep the latest code somewhere else? Okay I figured it out. CVS head is out of date, the "commapi-0-0-1" revision contains the correct files. Gili From tjarvi at qbang.org Sun Apr 5 11:05:43 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Apr 2009 11:05:43 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D8E26B.2040705@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> Message-ID: CVS HEAD is currently the rxtx 2.0 code. A branch was created long ago for 'experimental' gnu.io work. It just happens that the branch is what everyone uses now. checkout -r commapi-0-0-1 rxtx-devel will get the branch On Sun, 5 Apr 2009, cowwoc wrote: > Trent Jarvi wrote: >> It will compile with the msvc cl.exe and nmake. See Makefile.msvc in the >> top level directory. You will need to adjust the JAVA_HOME variable. Also >> use the MSVC command prompt for x86_64 so cl and nmake are on your path. > > This is very odd. The CVS version of the code does not contain this > file. Do you keep the latest code somewhere else? > > Gili > From cowwoc at bbs.darktech.org Sun Apr 5 14:50:47 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 16:50:47 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> Message-ID: <49D919A7.1070806@bbs.darktech.org> Okay, I tracked down the crash. It's being caused by YACK() using a 80-character buffer. The error message is longer than 80 characters, so _snprintf_s() crashes to avoid a buffer overflow. Please apply the attached patch and add the zipped up Visual Studio project directory. It's not perfect yet but it's a good start. Gili Trent Jarvi wrote: > > CVS HEAD is currently the rxtx 2.0 code. A branch was created long > ago for 'experimental' gnu.io work. It just happens that the branch > is what everyone uses now. > > checkout -r commapi-0-0-1 rxtx-devel > > will get the branch > > On Sun, 5 Apr 2009, cowwoc wrote: > >> Trent Jarvi wrote: >>> It will compile with the msvc cl.exe and nmake. See Makefile.msvc >>> in the top level directory. You will need to adjust the JAVA_HOME >>> variable. Also use the MSVC command prompt for x86_64 so cl and >>> nmake are on your path. >> >> This is very odd. The CVS version of the code does not contain >> this file. Do you keep the latest code somewhere else? >> >> Gili >> -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx-devel.patch Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20090405/d9b82962/attachment-0010.pl -------------- next part -------------- A non-text attachment was scrubbed... Name: Win32.zip Type: application/octet-stream Size: 17764 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20090405/d9b82962/attachment-0012.obj From cowwoc at bbs.darktech.org Sun Apr 5 15:22:01 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 17:22:01 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D919A7.1070806@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> <49D919A7.1070806@bbs.darktech.org> Message-ID: <49D920F9.6080702@bbs.darktech.org> My mistake. The problem in YACK is real, but it isn't the real cause of the crash. The crash is caused by termios.c line 1099: index->prev->next = port; because in my case "index->prev==0". I think the bug is that the code assumes that index will contain a minimum of two entries if we're inserting a previously closed fd. In my case, it only contains one. I'm not sure why you have this code branch (as opposed to appending to the end of index). Please take a look. Thanks, Gili cowwoc wrote: > > Okay, I tracked down the crash. It's being caused by YACK() using a > 80-character buffer. The error message is longer than 80 characters, so > _snprintf_s() crashes to avoid a buffer overflow. > > Please apply the attached patch and add the zipped up Visual Studio > project directory. It's not perfect yet but it's a good start. > > Gili > > Trent Jarvi wrote: >> >> CVS HEAD is currently the rxtx 2.0 code. A branch was created long >> ago for 'experimental' gnu.io work. It just happens that the branch >> is what everyone uses now. >> >> checkout -r commapi-0-0-1 rxtx-devel >> >> will get the branch >> >> On Sun, 5 Apr 2009, cowwoc wrote: >> >>> Trent Jarvi wrote: >>>> It will compile with the msvc cl.exe and nmake. See Makefile.msvc >>>> in the top level directory. You will need to adjust the JAVA_HOME >>>> variable. Also use the MSVC command prompt for x86_64 so cl and >>>> nmake are on your path. >>> >>> This is very odd. The CVS version of the code does not contain >>> this file. Do you keep the latest code somewhere else? >>> >>> Gili >>> From tjarvi at qbang.org Sun Apr 5 16:13:27 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Apr 2009 16:13:27 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D920F9.6080702@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> <49D919A7.1070806@bbs.darktech.org> <49D920F9.6080702@bbs.darktech.org> Message-ID: Hi Gili, Are you using the cvs version? I thought we fixed the linked list issues. A solution was posted to the list. Let me look at work tomorrow to see what I have. On Sun, 5 Apr 2009, cowwoc wrote: > > My mistake. The problem in YACK is real, but it isn't the real cause > of the crash. The crash is caused by termios.c line 1099: > > index->prev->next = port; > > because in my case "index->prev==0". I think the bug is that the code > assumes that index will contain a minimum of two entries if we're inserting a > previously closed fd. In my case, it only contains one. > > I'm not sure why you have this code branch (as opposed to appending > to the end of index). Please take a look. > > Thanks, > Gili > > cowwoc wrote: >> >> Okay, I tracked down the crash. It's being caused by YACK() using a >> 80-character buffer. The error message is longer than 80 characters, so >> _snprintf_s() crashes to avoid a buffer overflow. >> >> Please apply the attached patch and add the zipped up Visual Studio >> project directory. It's not perfect yet but it's a good start. >> >> Gili >> >> Trent Jarvi wrote: >>> >>> CVS HEAD is currently the rxtx 2.0 code. A branch was created long ago >>> for 'experimental' gnu.io work. It just happens that the branch is what >>> everyone uses now. >>> >>> checkout -r commapi-0-0-1 rxtx-devel >>> >>> will get the branch >>> >>> On Sun, 5 Apr 2009, cowwoc wrote: >>> >>>> Trent Jarvi wrote: >>>>> It will compile with the msvc cl.exe and nmake. See Makefile.msvc in >>>>> the top level directory. You will need to adjust the JAVA_HOME >>>>> variable. Also use the MSVC command prompt for x86_64 so cl and nmake >>>>> are on your path. >>>> >>>> This is very odd. The CVS version of the code does not contain this >>>> file. Do you keep the latest code somewhere else? >>>> >>>> Gili >>>> > From ilkka at myller.com Sun Apr 5 23:58:08 2009 From: ilkka at myller.com (Ilkka Myller) Date: Mon, 6 Apr 2009 08:58:08 +0300 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> <49D919A7.1070806@bbs.darktech.org> <49D920F9.6080702@bbs.darktech.org> Message-ID: <19779C97-E0C7-4E3D-B715-F84F50F00CE6@myller.com> Hi all, I've already submitted the patch to fix this issue in february: http://mailman.qbang.org/pipermail/rxtx/2009-February/3989441.html The patch fixes the mentioned doubly linked list handling in termios.c -- I Trent Jarvi kirjoitti 6.4.2009 kello 1.13: > > Hi Gili, > > Are you using the cvs version? I thought we fixed the linked list > issues. > A solution was posted to the list. Let me look at work tomorrow to > see > what I have. > > > > On Sun, 5 Apr 2009, cowwoc wrote: > >> >> My mistake. The problem in YACK is real, but it isn't the real cause >> of the crash. The crash is caused by termios.c line 1099: >> >> index->prev->next = port; >> >> because in my case "index->prev==0". I think the bug is that the >> code >> assumes that index will contain a minimum of two entries if we're >> inserting a >> previously closed fd. In my case, it only contains one. >> >> I'm not sure why you have this code branch (as opposed to appending >> to the end of index). Please take a look. >> >> Thanks, >> Gili >> >> cowwoc wrote: >>> >>> Okay, I tracked down the crash. It's being caused by YACK() >>> using a >>> 80-character buffer. The error message is longer than 80 >>> characters, so >>> _snprintf_s() crashes to avoid a buffer overflow. >>> >>> Please apply the attached patch and add the zipped up Visual >>> Studio >>> project directory. It's not perfect yet but it's a good start. >>> >>> Gili >>> >>> Trent Jarvi wrote: >>>> >>>> CVS HEAD is currently the rxtx 2.0 code. A branch was created >>>> long ago >>>> for 'experimental' gnu.io work. It just happens that the branch >>>> is what >>>> everyone uses now. >>>> >>>> checkout -r commapi-0-0-1 rxtx-devel >>>> >>>> will get the branch >>>> >>>> On Sun, 5 Apr 2009, cowwoc wrote: >>>> >>>>> Trent Jarvi wrote: >>>>>> It will compile with the msvc cl.exe and nmake. See >>>>>> Makefile.msvc in >>>>>> the top level directory. You will need to adjust the JAVA_HOME >>>>>> variable. Also use the MSVC command prompt for x86_64 so cl and >>>>>> nmake >>>>>> are on your path. >>>>> >>>>> This is very odd. The CVS version of the code does not >>>>> contain this >>>>> file. Do you keep the latest code somewhere else? >>>>> >>>>> Gili >>>>> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Steffen.DETTMER at ingenico.com Mon Apr 6 02:53:47 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 6 Apr 2009 10:53:47 +0200 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D919A7.1070806@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> <49D919A7.1070806@bbs.darktech.org> Message-ID: <20090406085347.GM8289@elberon.bln.de.ingenico.com> Hi, just two minor details, first about the errno change, I though #include extern int errno; is correct (POSIX.1) - why this change? second about the log message, I think the maximum length could be limited and the return value of malloc must be checked for != NULL before using. Should it be _snprintf_s( message, 80, _TRUNCATE, "Error 0x%x at %s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); (I know that MS-CRT _snprintf does not guarantee to have a final EOS, but I think _snprintf_s with _TRUNCATE does so?). If it is known that truncation may happen maybe sizeof[message] could be increased; maybe using some %.20s could be used avoiding __FILE__ including big pathes to a message where all the message had been cut-off. To have it portable I think it could be: /* generally: */ #if defined(_MSC_VER) # define snprintf _snprintf #endif snprintf(message, sizeof(message), "Error 0x%x at %.20s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); message[sizeof(message)-1] = '\0'; /* needed for MS CRT snprintf */ (for length and size parameter I think size_t could be an option, but on several platforms, including MS-CRT and older glibc, there is no %z, unfortunately) oki, Steffen * cowwoc wrote on Sun, Apr 05, 2009 at 16:50 -0400: > > Okay, I tracked down the crash. It's being caused by YACK() using a > 80-character buffer. The error message is longer than 80 characters, so > _snprintf_s() crashes to avoid a buffer overflow. > > Please apply the attached patch and add the zipped up Visual Studio > project directory. It's not perfect yet but it's a good start. > > Gili > > Trent Jarvi wrote: > > > >CVS HEAD is currently the rxtx 2.0 code. A branch was created long > >ago for 'experimental' gnu.io work. It just happens that the branch > >is what everyone uses now. > > > >checkout -r commapi-0-0-1 rxtx-devel > > > >will get the branch > > > >On Sun, 5 Apr 2009, cowwoc wrote: > > > >>Trent Jarvi wrote: > >>>It will compile with the msvc cl.exe and nmake. See Makefile.msvc > >>>in the top level directory. You will need to adjust the JAVA_HOME > >>>variable. Also use the MSVC command prompt for x86_64 so cl and > >>>nmake are on your path. > >> > >> This is very odd. The CVS version of the code does not contain > >>this file. Do you keep the latest code somewhere else? > >> > >>Gili > >> > Index: ParallelImp.c > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/ParallelImp.c,v > retrieving revision 1.15.2.36 > diff -u -r1.15.2.36 ParallelImp.c > --- ParallelImp.c 11 Feb 2009 01:04:19 -0000 1.15.2.36 > +++ ParallelImp.c 5 Apr 2009 17:55:23 -0000 > @@ -119,7 +119,7 @@ > # include > #endif > > -extern int errno; > +_CRTIMP extern int * __cdecl _errno(void); > > #include "ParallelImp.h" > > @@ -181,8 +181,6 @@ > > #if defined (WIN32) > > -#define CTL_CODE( DeviceType, Function, Method, Access ) (((DeviceType) << 16) | ((Access) << 14) | ((Function) << 2) | (Method)) > - > #define FILE_DEVICE_PARALLEL_PORT 0x00000016 > #define METHOD_BUFFERED 0 > #define FILE_ANY_ACCESS 0 > @@ -253,7 +251,6 @@ > jobject jobj) > { > int fd = get_java_var( env, jobj,"fd","I" ); > - int status; > #if defined (__linux__) > ioctl(fd, LPGETSTATUS, &status); > #elif defined (WIN32) > Index: SerialImp.c > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v > retrieving revision 1.46.2.203 > diff -u -r1.46.2.203 SerialImp.c > --- SerialImp.c 19 Mar 2009 03:27:48 -0000 1.46.2.203 > +++ SerialImp.c 5 Apr 2009 17:49:48 -0000 > @@ -147,7 +147,7 @@ > #include > #endif /* LIBLOCKDEV */ > > -extern int errno; > +_CRTIMP extern int * __cdecl _errno(void); > > #include "SerialImp.h" > > Index: termios.c > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/termios.c,v > retrieving revision 1.9.2.62 > diff -u -r1.9.2.62 termios.c > --- termios.c 13 Jan 2009 03:08:55 -0000 1.9.2.62 > +++ termios.c 5 Apr 2009 17:54:09 -0000 > @@ -88,7 +88,7 @@ > #define SIGIO 0 > > int my_errno; > -extern int errno; > +_CRTIMP extern int * __cdecl _errno(void); > struct termios_list > { > char filename[80]; > @@ -1350,7 +1350,7 @@ > In that case use EAGAIN. See SerialImp.c:testRead() > ----------------------------------------------------------*/ > > -int serial_read( int fd, void *vb, int size ) > +int serial_read( int fd, void *vb, unsigned int size ) > { > long start, now; > unsigned long nBytes = 0, total = 0, error; > Index: win32termios.h > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/win32termios.h,v > retrieving revision 1.5.2.34 > diff -u -r1.5.2.34 win32termios.h > --- win32termios.h 5 Feb 2009 01:25:05 -0000 1.5.2.34 > +++ win32termios.h 5 Apr 2009 20:29:30 -0000 > @@ -60,6 +60,7 @@ > #include > #include > #include > +#include > #ifdef TRACE > #define ENTER(x) report("entering "x" \n"); > #define LEAVE(x) report("leaving "x" \n"); > @@ -70,8 +71,9 @@ > #if defined(_MSC_VER) > #define YACK() \ > { \ > - char *allocTextBuf, message[80]; \ > - unsigned long nChars; \ > + char *allocTextBuf, *message; \ > + const unsigned short longestNumber = 20; \ > + unsigned long nChars, len; \ > unsigned int errorCode = GetLastError(); \ > nChars = FormatMessage ( \ > FORMAT_MESSAGE_ALLOCATE_BUFFER | \ > @@ -82,8 +84,12 @@ > (LPSTR)&allocTextBuf, \ > 16, \ > NULL ); \ > - _snprintf_s( message, 80, 80, "Error 0x%x at %s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); \ > + len = strlen("Error 0x") + longestNumber + strlen(" at ") + strlen(__FILE__) + longestNumber + \ > + strlen(": ") + ((nChars+1) * sizeof(TCHAR)) + 1; \ > + message = malloc(len); \ > + _snprintf_s( message, len, len - 1, "Error 0x%x at %s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); \ > report_error( message ); \ > + free(message); \ > LocalFree(allocTextBuf); \ > Sleep(1); \ > } > @@ -173,7 +179,7 @@ > int serial_test( char * ); > int serial_open(const char *File, int flags, ... ); > int serial_close(int fd); > -int serial_read(int fd, void *b, int size); > +int serial_read(int fd, void *b, unsigned int size); > int serial_write(int fd, char *Str, int length); > /* > * lcc winsock.h conflicts > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx End of message. ------------------------------------------------------------------->8======= About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From bill7007 at gmail.com Mon Apr 6 16:34:50 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Mon, 6 Apr 2009 18:34:50 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: <49D693BA.8060909@gatworks.com> References: <49D546F8.20807@gatworks.com> <49D693BA.8060909@gatworks.com> Message-ID: Once it hung, three stack dumps minutes apart were exactly the same. I have a noticed that when it hangs, the read appears after flush() enter and before flush leave() that doesn't happen like: RXTXPort:SerialOutputStream:flush() enter RXTXPort:SerialInputStream:read(8192 0 8192) called When it works, flush() enter and leave happen together. It may just be because flush() hangs and read is the only other thread waiting to run at that point. I don't know much about the RXTX design and kernel interaction, just digging through the code some. Is there a design description somewhere? Am hung up on target system compile since UTS_RELEASE seems no longer defined for 2.6.18 up kernels and have not figured a good patch yet. But, that is another issue. Thanks for the good help. On Fri, Apr 3, 2009 at 6:54 PM, U. George wrote: > I would have tried 2 or 3 "^\" . If things are stuck, then all will be at > same 'java' instruction. If thread is moving, then one of the snapshots > would be different. > > I *think* flushing/draining wont return until the kernel buffers to device > have been accepted by device. Stuck/paused device? > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090406/c4b509d8/attachment-0011.html From tjarvi at qbang.org Mon Apr 6 17:45:38 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 6 Apr 2009 17:45:38 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <20090406085347.GM8289@elberon.bln.de.ingenico.com> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> <49D919A7.1070806@bbs.darktech.org> <20090406085347.GM8289@elberon.bln.de.ingenico.com> Message-ID: The error bits in the patch can probably just be dropped out. I don't see what they solve. Your snprintf define appears to work. The following is what I'd like to put in if noone objects. #if defined(_MSC_VER) # define snprintf _snprintf #endif #define YACK() \ { \ char *allocTextBuf, message[80]; \ unsigned long nChars; \ unsigned int errorCode = GetLastError(); \ nChars = FormatMessage ( \ FORMAT_MESSAGE_ALLOCATE_BUFFER | \ FORMAT_MESSAGE_FROM_SYSTEM, \ NULL, \ errorCode, \ MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT), \ (LPSTR)&allocTextBuf, \ 16, \ NULL ); \ snprintf( message, 80, "Error 0x%x at %s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); \ message[sizeof(message)-1] = '\0'; /* needed for MS CRT snprintf */ \ report_error( message ); \ LocalFree(allocTextBuf); \ Sleep(1); \ } On Mon, 6 Apr 2009, Steffen DETTMER wrote: > Hi, > > just two minor details, first about the errno change, I though > > #include > extern int errno; > > is correct (POSIX.1) - why this change? > > second about the log message, I think the maximum length could be > limited and the return value of malloc must be checked for != > NULL before using. > > Should it be > > _snprintf_s( message, 80, _TRUNCATE, "Error 0x%x at %s(%d): %s\n", > errorCode, __FILE__, __LINE__, allocTextBuf); > > (I know that MS-CRT _snprintf does not guarantee to have a final > EOS, but I think _snprintf_s with _TRUNCATE does so?). > > If it is known that truncation may happen maybe sizeof[message] > could be increased; maybe using some %.20s could be used avoiding > __FILE__ including big pathes to a message where all the message > had been cut-off. > > To have it portable I think it could be: > > /* generally: */ > #if defined(_MSC_VER) > # define snprintf _snprintf > #endif > > snprintf(message, sizeof(message), "Error 0x%x at %.20s(%d): %s\n", > errorCode, __FILE__, __LINE__, allocTextBuf); > message[sizeof(message)-1] = '\0'; /* needed for MS CRT snprintf */ > > (for length and size parameter I think size_t could be an option, > but on several platforms, including MS-CRT and older glibc, > there is no %z, unfortunately) > > oki, > > Steffen > > > * cowwoc wrote on Sun, Apr 05, 2009 at 16:50 -0400: >> >> Okay, I tracked down the crash. It's being caused by YACK() using a >> 80-character buffer. The error message is longer than 80 characters, so >> _snprintf_s() crashes to avoid a buffer overflow. >> >> Please apply the attached patch and add the zipped up Visual Studio >> project directory. It's not perfect yet but it's a good start. >> >> Gili >> >> Trent Jarvi wrote: >> > >> >CVS HEAD is currently the rxtx 2.0 code. A branch was created long >> >ago for 'experimental' gnu.io work. It just happens that the branch >> >is what everyone uses now. >> > >> >checkout -r commapi-0-0-1 rxtx-devel >> > >> >will get the branch >> > >> >On Sun, 5 Apr 2009, cowwoc wrote: >> > >> >>Trent Jarvi wrote: >> >>>It will compile with the msvc cl.exe and nmake. See Makefile.msvc >> >>>in the top level directory. You will need to adjust the JAVA_HOME >> >>>variable. Also use the MSVC command prompt for x86_64 so cl and >> >>>nmake are on your path. >> >> >> >> This is very odd. The CVS version of the code does not contain >> >>this file. Do you keep the latest code somewhere else? >> >> >> >>Gili >> >> > >> Index: ParallelImp.c >> =================================================================== >> RCS file: /usr/local/cvsroot/rxtx-devel/src/ParallelImp.c,v >> retrieving revision 1.15.2.36 >> diff -u -r1.15.2.36 ParallelImp.c >> --- ParallelImp.c 11 Feb 2009 01:04:19 -0000 1.15.2.36 >> +++ ParallelImp.c 5 Apr 2009 17:55:23 -0000 >> @@ -119,7 +119,7 @@ >> # include >> #endif >> >> -extern int errno; >> +_CRTIMP extern int * __cdecl _errno(void); >> >> #include "ParallelImp.h" >> >> @@ -181,8 +181,6 @@ >> >> #if defined (WIN32) >> >> -#define CTL_CODE( DeviceType, Function, Method, Access ) (((DeviceType) << 16) | ((Access) << 14) | ((Function) << 2) | (Method)) >> - >> #define FILE_DEVICE_PARALLEL_PORT 0x00000016 >> #define METHOD_BUFFERED 0 >> #define FILE_ANY_ACCESS 0 >> @@ -253,7 +251,6 @@ >> jobject jobj) >> { >> int fd = get_java_var( env, jobj,"fd","I" ); >> - int status; >> #if defined (__linux__) >> ioctl(fd, LPGETSTATUS, &status); >> #elif defined (WIN32) >> Index: SerialImp.c >> =================================================================== >> RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v >> retrieving revision 1.46.2.203 >> diff -u -r1.46.2.203 SerialImp.c >> --- SerialImp.c 19 Mar 2009 03:27:48 -0000 1.46.2.203 >> +++ SerialImp.c 5 Apr 2009 17:49:48 -0000 >> @@ -147,7 +147,7 @@ >> #include >> #endif /* LIBLOCKDEV */ >> >> -extern int errno; >> +_CRTIMP extern int * __cdecl _errno(void); >> >> #include "SerialImp.h" >> >> Index: termios.c >> =================================================================== >> RCS file: /usr/local/cvsroot/rxtx-devel/src/termios.c,v >> retrieving revision 1.9.2.62 >> diff -u -r1.9.2.62 termios.c >> --- termios.c 13 Jan 2009 03:08:55 -0000 1.9.2.62 >> +++ termios.c 5 Apr 2009 17:54:09 -0000 >> @@ -88,7 +88,7 @@ >> #define SIGIO 0 >> >> int my_errno; >> -extern int errno; >> +_CRTIMP extern int * __cdecl _errno(void); >> struct termios_list >> { >> char filename[80]; >> @@ -1350,7 +1350,7 @@ >> In that case use EAGAIN. See SerialImp.c:testRead() >> ----------------------------------------------------------*/ >> >> -int serial_read( int fd, void *vb, int size ) >> +int serial_read( int fd, void *vb, unsigned int size ) >> { >> long start, now; >> unsigned long nBytes = 0, total = 0, error; >> Index: win32termios.h >> =================================================================== >> RCS file: /usr/local/cvsroot/rxtx-devel/src/win32termios.h,v >> retrieving revision 1.5.2.34 >> diff -u -r1.5.2.34 win32termios.h >> --- win32termios.h 5 Feb 2009 01:25:05 -0000 1.5.2.34 >> +++ win32termios.h 5 Apr 2009 20:29:30 -0000 >> @@ -60,6 +60,7 @@ >> #include >> #include >> #include >> +#include >> #ifdef TRACE >> #define ENTER(x) report("entering "x" \n"); >> #define LEAVE(x) report("leaving "x" \n"); >> @@ -70,8 +71,9 @@ >> #if defined(_MSC_VER) >> #define YACK() \ >> { \ >> - char *allocTextBuf, message[80]; \ >> - unsigned long nChars; \ >> + char *allocTextBuf, *message; \ >> + const unsigned short longestNumber = 20; \ >> + unsigned long nChars, len; \ >> unsigned int errorCode = GetLastError(); \ >> nChars = FormatMessage ( \ >> FORMAT_MESSAGE_ALLOCATE_BUFFER | \ >> @@ -82,8 +84,12 @@ >> (LPSTR)&allocTextBuf, \ >> 16, \ >> NULL ); \ >> - _snprintf_s( message, 80, 80, "Error 0x%x at %s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); \ >> + len = strlen("Error 0x") + longestNumber + strlen(" at ") + strlen(__FILE__) + longestNumber + \ >> + strlen(": ") + ((nChars+1) * sizeof(TCHAR)) + 1; \ >> + message = malloc(len); \ >> + _snprintf_s( message, len, len - 1, "Error 0x%x at %s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); \ >> report_error( message ); \ >> + free(message); \ >> LocalFree(allocTextBuf); \ >> Sleep(1); \ >> } >> @@ -173,7 +179,7 @@ >> int serial_test( char * ); >> int serial_open(const char *File, int flags, ... ); >> int serial_close(int fd); >> -int serial_read(int fd, void *b, int size); >> +int serial_read(int fd, void *b, unsigned int size); >> int serial_write(int fd, char *Str, int length); >> /* >> * lcc winsock.h conflicts >> > > >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > > > > > > > > > > > > End of message. > ------------------------------------------------------------------->8======= > > > About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. > This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > P Please consider the environment before printing this e-mail > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Apr 6 18:11:28 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 6 Apr 2009 18:11:28 -0600 (MDT) Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: <49D546F8.20807@gatworks.com> <49D693BA.8060909@gatworks.com> Message-ID: UTS_RELEASE is defined in now. The check really should be removed from RXTX. It was a defensive check for wilder times when GNU glibc did not have defines the kernel headers had so rxtx would include the kernel headers instead. :/ If you don't have linux/version.h, it is generated when you configure the kernel. make oldconfig used to do the trick. It may make sense to work with the prerelease or CVS code. RXTX just assumes that flush, read and anything else the kernel exposes may be called at anytime from any thread. There isn't a design for the kernel interaction. There are higher level constraints put in Java to prevent some things happening at the same time with 'synchronized.' RXTXPort.java has all of those. When the port is opened, a native event thread is started which uses select to know if an event has happened. BSD like systems have a native thread that fires off on write which tries to flush() to determine when the output buffer is empty asynchronously. The rest is not marshaled in any fashion at the native level. T I think there is a lower level deadlock being triggered in flush as well. I don't think it should be possible if everything was right underneath us. You may want to examine the java code closer to make sure it isnt possible the lock is there. On Mon, 6 Apr 2009, Bill Johnson wrote: > Once it hung, three stack dumps minutes apart were exactly the same. > I have a noticed that when it hangs, the read appears after flush() enter and > before flush leave() that doesn't happen like: > RXTXPort:SerialOutputStream:flush() enter > RXTXPort:SerialInputStream:read(8192 0 8192) called > > When it works, flush() enter and leave happen together. It may just be because > flush() hangs and read is the only other thread waiting to run at that point. > I don't know much about the RXTX design and kernel interaction, just digging > through the code some. Is there a design description somewhere? > > Am hung up on target system compile since UTS_RELEASE seems no longer defined for > 2.6.18 up kernels and have not figured a good patch yet. But, that is another > issue. > > Thanks for the good help. > > > On Fri, Apr 3, 2009 at 6:54 PM, U. George wrote: > I would have tried 2 or 3 "^\" . If things are stuck, then all will be > at same 'java' instruction. If thread is moving, then one of the > snapshots would be different. > > I *think* flushing/draining wont return until the kernel buffers to > device have been accepted by device. Stuck/paused device? > > > > > From tjarvi at qbang.org Mon Apr 6 18:28:50 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 6 Apr 2009 18:28:50 -0600 (MDT) Subject: [Rxtx] CVS updates. Pre3 is comming. Message-ID: I need to go through the bugzilla reports prior to the pre3 release. I think this should be close if you want to check it out from CVS. added: YACK() debug overflow fix for windows Steffen DETTMER (and many others) multiport fix for windows. Ilkka Myller http://mailman.qbang.org/pipermail/rxtx/2009-February/3989441.html I think this code is current. If I missed something, yell. CVS Info: export/setenv CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login # passwd mousy cvs checkout -r commapi-0-0-1 rxtx-devel -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Apr 6 22:32:07 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 6 Apr 2009 22:32:07 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D919A7.1070806@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> <49D919A7.1070806@bbs.darktech.org> Message-ID: Ah. I'll put this in CVS tomorrow. I did sync up the code with my work sandbox today. I just forgot to pull and add this. On Sun, 5 Apr 2009, cowwoc wrote: > > Okay, I tracked down the crash. It's being caused by YACK() using a > 80-character buffer. The error message is longer than 80 characters, so > _snprintf_s() crashes to avoid a buffer overflow. > > Please apply the attached patch and add the zipped up Visual Studio > project directory. It's not perfect yet but it's a good start. > > Gili > > Trent Jarvi wrote: >> >> CVS HEAD is currently the rxtx 2.0 code. A branch was created long ago for >> 'experimental' gnu.io work. It just happens that the branch is what >> everyone uses now. >> >> checkout -r commapi-0-0-1 rxtx-devel >> >> will get the branch >> >> On Sun, 5 Apr 2009, cowwoc wrote: >> >>> Trent Jarvi wrote: >>>> It will compile with the msvc cl.exe and nmake. See Makefile.msvc in the >>>> top level directory. You will need to adjust the JAVA_HOME variable. >>>> Also use the MSVC command prompt for x86_64 so cl and nmake are on your >>>> path. >>> >>> This is very odd. The CVS version of the code does not contain this >>> file. Do you keep the latest code somewhere else? >>> >>> Gili >>> > From cowwoc at bbs.darktech.org Tue Apr 7 06:07:46 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Tue, 07 Apr 2009 08:07:46 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: References: Message-ID: <49DB4212.40807@bbs.darktech.org> > just two minor details, first about the errno change, I though > > #include > extern int errno; > > is correct (POSIX.1) - why this change? If you compile this under Visual Studio 2008 you will get warnings that the errno type being imported is different from the type being exported. The definition I pasted is the one being exported. Perhaps we should use #ifdef WIN32 for this? Gili From bill7007 at gmail.com Tue Apr 7 17:58:54 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Tue, 7 Apr 2009 19:58:54 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: <49D546F8.20807@gatworks.com> <49D693BA.8060909@gatworks.com> Message-ID: I have traced the hang down to a call to tcdrain(fd) in SerialImp.c:drain() running and rebuilt under Netbeans on the target machine with debug messages on. That puts it into the system code, so I'm not sure how to proceed. I guess I could debug into the kernel source but I've not done that. I saw some discussion about an IOCTL that sets/adjusts a timeout on tcdrain() but that may have been for BSD. Maybe there is some new setup requirement or bug introduced with this 2.6.18 kernel or a hardware difference. Below is a message listing with some of the repeated parts removed. Maybe you can see something noteworthy? JNI_OnLoad called. WARNING: RXTX Version mismatch Jar version = RXTX-2.2pre2 native lib Version = RXTX-2.2pre3 entering RXTXCommDriver:getDeviceDirectory entering RXTXPort:testRead fhs_lock: creating lockfile: 29704 fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXPort:testRead RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB2 fhs_lock: creating lockfile: 29704 fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXPort:testRead RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB1 fhs_lock: creating lockfile: 29704 fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXPort:testRead RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB0 fhs_lock: creating lockfile: 29704 fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXPort:testRead fhs_lock: creating lockfile: 29704 ... REPEATS fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXPort:testRead fhs_lock: creating lockfile: 29704 fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXCommDriver:getDeviceDirectory entering RXTXPort:testRead fhs_lock: creating lockfile: 29704 ...REPEATS fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXPort:testRead fhs_lock: creating lockfile: 29704 fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXPort:Initialize RXTX WARNING: This library was compiled to run with OS release 2.6.18 and you are currently running OS release 2.6.18-92.1.6.el5. In some cases this can be a problem. Try recompiling RXTX if you notice strange behavior. If you just compiled RXTX make sure /usr/include/linux is a symbolic link to the include files that came with the kernel source and not an older copy. press enter to continue leaving RXTXPort:Initialize entering RXTXPort:open fhs_lock: creating lockfile: 29704 open: locking worked for /dev/ttyUSB2 open: fd returned is 9 leaving RXTXPort:open entering eventLoop has_line_status_register_acess: Port does not support TIOCSERGETLSR driver_has_tiocgicount: Port does not support TIOCGICOUNT events init_threads: get eis init_threads: set eis init_threads: stop leaving RXTXPort:translate_speed entering RXTXPort:nativeSetSerialPortParams entering translate_date_bits entering translate_stop_bits leaving RXTXPort:translate_stop_bits entering translate_parity leaving translate_parity entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 ...REPEATS entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 leaving RXTXPort:nativeSetSerialPortParams entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 ...REPEATS entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 entering writeArray entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 writeArray() leaving RXTXPort:writeArray entering SerialImp.c:drain() nativeDrain: trying tcdrain RXTXPort:drain() returns: 0 leaving RXTXPort:drain() entering writeArray writeArray() leaving RXTXPort:writeArray entering SerialImp.c:drain() nativeDrain: trying tcdrain entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 Tue Apr 07 18:51:49 EDT 2009:TSerial[22]:Using Port:/dev/ttyUSB2 Tue Apr 07 18:51:49 EDT 2009:TSerial[22].Transmit:TN Tue Apr 07 18:51:49 EDT 2009:TSerial[22].Transmit:RV entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 ...REPEATS FOREVER? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090407/f26e5752/attachment-0010.html From tjarvi at qbang.org Tue Apr 7 18:31:23 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 7 Apr 2009 18:31:23 -0600 (MDT) Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: <49D546F8.20807@gatworks.com> <49D693BA.8060909@gatworks.com> Message-ID: On Tue, 7 Apr 2009, Bill Johnson wrote: > I have traced the hang down to a call to tcdrain(fd) in SerialImp.c:drain() > running and rebuilt under Netbeans on the target machine with debug messages > on. That puts it into the system code, so I'm not sure how to proceed. I > guess I could debug into the kernel source but I've not done that. I saw > some discussion about an IOCTL that sets/adjusts a timeout on tcdrain() but > that may have been for BSD. Maybe there is some new setup requirement or bug > introduced with this 2.6.18 kernel or a hardware difference. > Below is a message listing with some of the repeated parts removed. Maybe > you can see something noteworthy? > > JNI_OnLoad called. > WARNING:? RXTX Version mismatch > ??????? Jar version = RXTX-2.2pre2 > ??????? native lib Version = RXTX-2.2pre3 > entering RXTXCommDriver:getDeviceDirectory > entering RXTXPort:testRead > fhs_lock: creating lockfile:????? 29704 > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXPort:testRead > RXTX Warning:? Removing stale lock file. /var/lock/LCK..ttyUSB2 > fhs_lock: creating lockfile:????? 29704 > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXPort:testRead > RXTX Warning:? Removing stale lock file. /var/lock/LCK..ttyUSB1 > fhs_lock: creating lockfile:????? 29704 > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXPort:testRead > RXTX Warning:? Removing stale lock file. /var/lock/LCK..ttyUSB0 > fhs_lock: creating lockfile:????? 29704 > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXPort:testRead > fhs_lock: creating lockfile:????? 29704 > > ... REPEATS > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXPort:testRead > fhs_lock: creating lockfile:????? 29704 > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXCommDriver:getDeviceDirectory > entering RXTXPort:testRead > fhs_lock: creating lockfile:????? 29704 > > ...REPEATS > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXPort:testRead > fhs_lock: creating lockfile:????? 29704 > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXPort:Initialize > > > > RXTX WARNING:? This library was compiled to run with OS release 2.6.18 and > you are currently running OS release 2.6.18-92.1.6.el5.? In some cases this > can be a problem.? Try recompiling RXTX if you notice strange behavior.? If > you just compiled RXTX make sure /usr/include/linux is a symbolic link to > the include files that came with the kernel source and not an older copy. > > > press enter to continue > > leaving RXTXPort:Initialize > entering RXTXPort:open > fhs_lock: creating lockfile:????? 29704 > > open: locking worked for /dev/ttyUSB2 > open: fd returned is 9 > leaving RXTXPort:open > entering eventLoop > ? > has_line_status_register_acess: Port does not support TIOCSERGETLSR > ?driver_has_tiocgicount:? Port does not support TIOCGICOUNT events > init_threads: get eis > init_threads: set eis > init_threads:? stop > leaving RXTXPort:translate_speed > entering RXTXPort:nativeSetSerialPortParams > entering translate_date_bits > entering translate_stop_bits > leaving RXTXPort:translate_stop_bits > entering translate_parity > leaving translate_parity > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > ...REPEATS > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > leaving RXTXPort:nativeSetSerialPortParams > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > ...REPEATS > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > entering writeArray > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > writeArray() > leaving RXTXPort:writeArray > entering SerialImp.c:drain() > nativeDrain: trying tcdrain > RXTXPort:drain() returns: 0 > leaving RXTXPort:drain() > entering writeArray > writeArray() > leaving RXTXPort:writeArray > entering SerialImp.c:drain() > nativeDrain: trying tcdrain > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > Tue Apr 07 18:51:49 EDT 2009:TSerial[22]:Using Port:/dev/ttyUSB2 > Tue Apr 07 18:51:49 EDT 2009:TSerial[22].Transmit:TN > > Tue Apr 07 18:51:49 EDT 2009:TSerial[22].Transmit:RV > > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > ...REPEATS FOREVER? > > > Hi Bill ugh. The tiocmget... is the eventLoop checking for events. It sits with select() but has a timeout value to keep it spinning at a trivial rate. tcdrain() is the suspect. I don't see anything in the code that looks like a problem. If flow control is not enabled, I don't see a reason for it not to return. Given that this is USB, perhaps a message from the device got lost. Onboard UARTs would have a status register change when output buffer is empty. USB needs to communicate the event as an HID device which may be the source of the error. Dropping back to onboard UARTs eliminates that portion of the mix. What vendor/chipset is the USB dongle? I understand code has been pushed upon the linux serial devices for new for things like acpi. There very well could be a bug introduced. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Apr 7 18:38:22 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 7 Apr 2009 18:38:22 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49DB4212.40807@bbs.darktech.org> References: <49DB4212.40807@bbs.darktech.org> Message-ID: On Tue, 7 Apr 2009, cowwoc wrote: >> just two minor details, first about the errno change, I though >> >> #include >> extern int errno; >> >> is correct (POSIX.1) - why this change? > > If you compile this under Visual Studio 2008 you will get warnings that > the errno type being imported is different from the type being exported. > The definition I pasted is the one being exported. Perhaps we should use > #ifdef WIN32 for this? > Hi Gili, Perhaps a workaround for _MSVC is in order. GNU compilers for windows won't complain. If it's a question of MSVC or POSIX being right, the library favors the standard as a stated goal. I'm not sure what MSVC is using errno for but it should not be using it except with POSIX extensions. Perhaps #undef is enough to get rid of the warning and (maybe) has no ill consequences. Newer windows have POSIX extensions that may show how Microsoft solved the problem. It can probably fester. -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Tue Apr 7 19:54:06 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Tue, 07 Apr 2009 21:54:06 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: References: <49DB4212.40807@bbs.darktech.org> Message-ID: <49DC03BE.5010203@bbs.darktech.org> Trent Jarvi wrote: > I'm not sure what MSVC is using errno for but it should not be using it > except with POSIX extensions. Perhaps #undef is enough to get rid of > the warning and (maybe) has no ill consequences. Newer windows have > POSIX extensions that may show how Microsoft solved the problem. > > It can probably fester. What does "newer windows" refer to in this case? I was compiling using Visual Studio 2008 sp1 under Windows Vista. Both are cutting edge technologies as far as official releases go. I think you're best suited to judge whether this warning is a big deal or not so I think you should see it for yourself. Please try firing up Visual Studio 2008 (express?) against the project I sent you. Gili From Steffen.DETTMER at ingenico.com Wed Apr 8 05:50:42 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 8 Apr 2009 13:50:42 +0200 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49DC03BE.5010203@bbs.darktech.org> References: <49DB4212.40807@bbs.darktech.org> <49DC03BE.5010203@bbs.darktech.org> Message-ID: <20090408115042.GC5090@elberon.bln.de.ingenico.com> * cowwoc wrote on Tue, Apr 07, 2009 at 21:54 -0400: > Trent Jarvi wrote: > > I'm not sure what MSVC is using errno for but it should not be using it > > except with POSIX extensions. Perhaps #undef is enough to get rid of > > the warning and (maybe) has no ill consequences. Newer windows have > > POSIX extensions that may show how Microsoft solved the problem. I think here best is simply to omit this old^Wclassic `extern int errno;' line completely. I think standards just say something like `implementations may support the declaration extern int errno;'. About POSIX extensions I think in general it should be considered that althrough many things are available, even with MS Visual C++, the Microsoft tools lead developers to write non-portable code (and personally I think this is intentional). For example, they call the official ISO-C function `strerror' deprecated (!) and twaddle about some security enhancements (without even beeing specific). Someone could, because of this, lead to use the MS specific, unportable `strerror_s' instead. Even better, at _strerror_s they tell, for `ANSI compatiblity someone should use strerror_s'. Of course a program using [_]strerror_s won't be ANSI-C compliant. Do they mean strerror_r? _strerror_s has the same parameters - but of course in different order - to make porting a pain... SCNR. > What does "newer windows" refer to in this case? I was compiling using > Visual Studio 2008 sp1 under Windows Vista. Both are cutting edge > technologies as far as official releases go. `cutting edge technologies' yeah post-standard, portability-cutting technologies smoothing the way to MS world domination; own post-ANSI-C programming languages help (maybe to increase the share holder value)... SCNR. > I think you're best suited to judge whether this warning is a big deal > or not so I think you should see it for yourself. Please try firing up > Visual Studio 2008 (express?) against the project I sent you. yeah, getting the CL.EXE of 2008 running in a normal command line environment (without its special `C++ Shell') is a bit tricky - but possible. ;) oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From tjarvi at qbang.org Wed Apr 8 14:29:54 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 8 Apr 2009 14:29:54 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49DC03BE.5010203@bbs.darktech.org> References: <49DB4212.40807@bbs.darktech.org> <49DC03BE.5010203@bbs.darktech.org> Message-ID: The support has been around for a long time to. I don't know the details but the support appears to be tied to the OS. http://en.wikipedia.org/wiki/POSIX#POSIX_for_Windows On Tue, 7 Apr 2009, cowwoc wrote: > Trent Jarvi wrote: >> I'm not sure what MSVC is using errno for but it should not be using it >> except with POSIX extensions. Perhaps #undef is enough to get rid of the >> warning and (maybe) has no ill consequences. Newer windows have POSIX >> extensions that may show how Microsoft solved the problem. >> >> It can probably fester. > > What does "newer windows" refer to in this case? I was compiling > using Visual Studio 2008 sp1 under Windows Vista. Both are cutting edge > technologies as far as official releases go. > > I think you're best suited to judge whether this warning is a big > deal or not so I think you should see it for yourself. Please try firing up > Visual Studio 2008 (express?) against the project I sent you. > > Gili > From bill7007 at gmail.com Wed Apr 8 15:59:08 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Wed, 8 Apr 2009 17:59:08 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: <49D546F8.20807@gatworks.com> <49D693BA.8060909@gatworks.com> Message-ID: Hi Trent, I think I have hit on a work around but don't know why it works. The USB serial adapter is a "CableMAX" based on Prolific's PL2303. Backing out to the big picture, the application is old and has been very reliable until put on a new cpu and kernel. It only hangs sometimes say 25% and always at the same place, at tcdrain() on the flush() after the second write after startup. If it made it past this stage, all transmit and receive seemed reliable so it was like a startup timing issue. Since learning to debug kernel code is beyond my immediate priority, I took a shot at moving code around, adding delays, and such. I have found it good practice to do a flush after every write on streams like: outputStream.write(data.getBytes()); outputStream.flush(); If I remove the flush() after each write, the problem appears to go away! I don't think the flush is needed for a SerialOutputStream for this application anyway. Thanks for all the help, +BillJ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090408/35d96a9d/attachment-0009.html From bill7007 at gmail.com Thu Apr 9 09:20:11 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Thu, 9 Apr 2009 11:20:11 -0400 Subject: [Rxtx] Baud rate fixes in 2.2pre2 breaks 38400 on some Linux devices Message-ID: Hello, An application that worked at 38400 on a USB serial adapter (PL2303) using 2.1-7-r2 on Linux EL4 (and EL5) now fails using 2.2pre2. serialPort.setSerialPortParams(38400,SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); throws an unsupportedCommOperationException This problem matched a description of Bug 113and I posted a proposed patch there, but I don't understand the whole custom baud rate patch so it may need some thought. An older patch, [Rxtx] [Patch]: Baud Rate fixes try 1, testing encouraged., fixed some custom baud rates but apparently broke 38400 on some Linux device. Other baud rates seem to work OK. And, 38400 tested OK on local non-USB ports. My proposed patch probably breaks the custom baud rate patch since it was keyed on 38400 as a special case for Linux and my fix was to back out part of that patch, specifically: #if defined(TIOCGSERIAL) if ( cspeed == B38400 ) cspeed = 38400; #endif /* TIOCGSERIAL */ +BillJ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090409/5636af64/attachment-0008.html From cowwoc at bbs.darktech.org Fri Apr 10 08:38:49 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Fri, 10 Apr 2009 10:38:49 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: References: <49DB4212.40807@bbs.darktech.org> <49DC03BE.5010203@bbs.darktech.org> Message-ID: <49DF59F9.2050408@bbs.darktech.org> Doesn't Wikipedia list as an optional sub-system? Gili Trent Jarvi wrote: > > The support has been around for a long time to. I don't know the > details but the support appears to be tied to the OS. > > http://en.wikipedia.org/wiki/POSIX#POSIX_for_Windows > > On Tue, 7 Apr 2009, cowwoc wrote: > >> Trent Jarvi wrote: >>> I'm not sure what MSVC is using errno for but it should not be using >>> it except with POSIX extensions. Perhaps #undef is enough to get >>> rid of the warning and (maybe) has no ill consequences. Newer >>> windows have POSIX extensions that may show how Microsoft solved the >>> problem. >>> >>> It can probably fester. >> >> What does "newer windows" refer to in this case? I was compiling >> using Visual Studio 2008 sp1 under Windows Vista. Both are cutting >> edge technologies as far as official releases go. >> >> I think you're best suited to judge whether this warning is a big >> deal or not so I think you should see it for yourself. Please try >> firing up Visual Studio 2008 (express?) against the project I sent you. >> >> Gili >> From eranshuman at gmail.com Mon Apr 13 04:50:34 2009 From: eranshuman at gmail.com (Anshuman Srivastava) Date: Mon, 13 Apr 2009 16:20:34 +0530 Subject: [Rxtx] Send RTS /DTR signal Message-ID: <589913a50904130350n59cc51ffvbcd0a4eaefb4ce5f@mail.gmail.com> Hi, I want to send the RTS or DTR signal from the application Can anybody telll how to send the DTR /RTS signal using rxtxcomm libraries Thanks and regards -- Anshuman Srivastava "... in the end, it's not the years in your life that count. It's the life in your years." Buzz +91 9962515155 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090413/211b5ded/attachment-0005.html From ajmas at sympatico.ca Mon Apr 13 09:50:47 2009 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 13 Apr 2009 11:50:47 -0400 Subject: [Rxtx] Wiki Spam pages - need of captcha? Message-ID: Hi Trent, While checking for spam pages in the wiki I came across a page containing the following: "NOTICE: This page was created by a program as part of the Graffiti Network research project at Brown University. We have removed the data, but are unable to remove this page. We apologize for any inconveniences that our actions may have caused. For more information, please visit http://graffiti.cs.brown.edu/info/." Is there any chance we could add a captcha to account registration? Andr?-John From sguido at micromotive.net Mon Apr 13 09:46:15 2009 From: sguido at micromotive.net (Samuel Guido) Date: Mon, 13 Apr 2009 11:46:15 -0400 Subject: [Rxtx] Serial Output Stream Hangs on Windows Message-ID: <843C9F1C-72EE-4A40-B02A-3798EB0C57BF@micromotive.net> All, I am using RXTX in a small application to talk to a remote embedded device on a Windows host. All data is ASCII text. On physical comm ports, everything seems to be fine, messages are sent and received without much trouble. I am also trying to make the comm port selection automatic where I cycle through the available comm ports sending messages until I get the expected response. Unfortunately, when I query for the available comm ports, the bluetooth ports also show up. Whenever I try to send a string of characters to the bluetooth port, RXTX hangs way down in the call stack in the output stream, I believe in the DLL. I tried both the 2.1.7r2 and the 2.2pre2 releases and both have the same result. The send and receiving of messages from the comm port are in their own threads, but once the thread is blocked, I can't do anything with the comm ports since they are synchronized calls. The bluetooth ports are using a driver call "WIDCOMM" which I don't know who/what that is. This is on a IBM T42 laptop machine. Does anyone know what could be causing this? Is there a way to distinguish between bluetooth ports and physical comm ports? Please help, I am on a tight deadline and any help would greatly be appreciated. Thanks very much. Sam Guido From ajmas at sympatico.ca Mon Apr 13 11:04:24 2009 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 13 Apr 2009 13:04:24 -0400 Subject: [Rxtx] RxTX mentioned on Sun's Java Communications page Message-ID: Looks like RxTx gets some mention at Sun: Head over to the Java Communications page http://java.sun.com/products/javacomm/ and then click on Downloads and you get: " COMM API is a Java extension providing access to RS-232 serial ports and IEEE-1284 parallel ports (SPP mode). Sun Ray platform support is provided. Documentation and sample code are included, as well as interactive test utilities. API serial features provide access to: * Port settings (baud rate, parity, stop bits) * Port naming, mapping, enumeration (configurable) * Data transfer over TX, RX lines * DTR, CD, CTS, RTS and DSR signals * Hardware/Software flow-control * Receive-buffer threshold control * Asynchronous events indicating: * Data available on an RS-232 port * Port hardware line level changes * Port ownership changes within a JVM Update History: * javax.comm 3.0, Update 1 o Fixed problems locating and parsing portmap.conf * javax.comm 3.0, FCS o Redesigned portmapping and Sun Ray interoperability (see bundled documentation) * 2.0.3: o Added portmapping (comm.jar available 'as-is' for 3rd party native lib support)* Several Bugfixes to 2.0.3 (see bundled release notes) Note: Sun no longer offer's the Windows platform binaries of javax.comm, however javax.comm 2.0.3 can be used for the Windows platform, by using it in conjunction with the Win32 implementation layer provided by the RxTx project. To use that, download javax.comm for the 'generic' platform (which provides the front-end javax.comm API only, without platform specific back-end implementations bundled). Then acquire the Windows binary implementation rxtx-2.0.7pre1 from http://www.rxtx.org . " Looks like RxTx really is the closest thing we have to the 'official' implementation. From tjarvi at qbang.org Mon Apr 13 12:27:44 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 13 Apr 2009 12:27:44 -0600 (MDT) Subject: [Rxtx] RxTX mentioned on Sun's Java Communications page In-Reply-To: References: Message-ID: On Mon, 13 Apr 2009, Andre-John Mas wrote: > Looks like RxTx gets some mention at Sun: > > Head over to the Java Communications page http://java.sun.com/products/javacomm/ > and then click on Downloads and you get: > > " > COMM API is a Java extension providing access to RS-232 serial ports > and IEEE-1284 parallel ports (SPP mode). Sun Ray platform support is > provided. Documentation and sample code are included, as well as > interactive test utilities. API serial features provide access to: * > Port settings (baud rate, parity, stop bits) * Port naming, mapping, > enumeration (configurable) * Data transfer over TX, RX lines * DTR, > CD, CTS, RTS and DSR signals * Hardware/Software flow-control * > Receive-buffer threshold control * Asynchronous events indicating: * > Data available on an RS-232 port * Port hardware line level changes * > Port ownership changes within a JVM Update History: * javax.comm 3.0, > Update 1 o Fixed problems locating and parsing portmap.conf * > javax.comm 3.0, FCS o Redesigned portmapping and Sun Ray > interoperability (see bundled documentation) * 2.0.3: o Added > portmapping (comm.jar available 'as-is' for 3rd party native lib > support)* Several Bugfixes to 2.0.3 (see bundled release notes) Note: > Sun no longer offer's the Windows platform binaries of javax.comm, > however javax.comm 2.0.3 can be used for the Windows platform, by > using it in conjunction with the Win32 implementation layer provided > by the RxTx project. To use that, download javax.comm for the > 'generic' platform (which provides the front-end javax.comm API only, > without platform specific back-end implementations bundled). Then > acquire the Windows binary implementation rxtx-2.0.7pre1 from http://www.rxtx.org > .. > " > > Looks like RxTx really is the closest thing we have to the 'official' > implementation. Ugh. I don't know of any developer interest in maintaining rxtx 2.0. It would be cleaner for Sun to just openly take javax.comm for their Sun Ray project. If someone is interested in maintaining rxtx 2.0, don't be afraid to say so. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Mon Apr 13 16:04:19 2009 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 13 Apr 2009 17:04:19 -0500 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D8DDEB.5010908@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> Message-ID: <49E3B6E3.5050203@cox.net> cowwoc wrote: > Trent Jarvi wrote: >> You are responsible for cleaning up the serial ports when using threads. >> That said, if the thread did shut down, finalize should have been called >> if you are not passing the object around. See RXTXPort.java. >> >> protected void finalize() >> { >> if (debug) >> z.reportln( "RXTXPort:finalize()"); >> if( fd > 0 ) >> { >> if (debug) >> z.reportln( "RXTXPort:calling close()"); >> close(); >> } >> z.finalize(); >> } > > Two points: > > 1) One should never rely on finalizers because they may never run. A PhantomRef is the way to do this kind of cleanup in most cases. It will always fire. The real issue is that you have to understand that the on the Sun JVM, the GC can run finalization or advertise a dropped reference before an object is actually unreferenced in some cases. This happens, predominately in blocks of code where object references are short lived with no class member reference that the GC can find. When the JIT compiled code just references an object on the local stack and/or a register, the GC can prematurely attempt finalization/PhantomRef notification and result in bad things happening. The single solution to this problem is to use synchronize(obj){} at the end of the block of code that obj lives in, which keeps the object from getting reclaimed prematurely. For the sake of application sanity and recovery from erroneous code, it's almost always best to put resources like this into a map, accessed by name, and make an API method that lets you find the object by name, rather than by instance reference. Then, in your code, when you want to open a serial port, you'd do something like the following, which will close anything you already opened and then open it back up. Map ports = ...; public void closePort( String port ) { CommPort p = null; p = ports.remove(port); if( p != null ) p.close(); } public CommPort public CommPort openPort( String port, String user, int timeout ) throws IOException { closePort( port ); CommPort p = CommPortIdentifier.getPortIdentifier(port). open( user, timeout ); ports.put( port, p ); return p; } Appropriate use of synchronized(ports) may be necessary if ports is not referencing a concurrency safe Map implementation such as Hashtable or ConcurrentHashMap. Gregg Wonderly From gergg at cox.net Mon Apr 13 16:36:57 2009 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 13 Apr 2009 17:36:57 -0500 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: <49D546F8.20807@gatworks.com> <49D693BA.8060909@gatworks.com> Message-ID: <49E3BE89.4020402@cox.net> Check CTS/RTS and DTR/CD etc on the device to make sure you haven't hung the kernel trying to clean up something, but it's now waiting for CTS etc. In general, you should be careful about using HW flow control when cables can be trivially unplugged or broken. Use application layer checksums or similar things to make sure data that is flowing is sane and that buffers have not overrun, resulting in lost data. Gregg Wonderly Trent Jarvi wrote: > UTS_RELEASE is defined in now. The check really should > be removed from RXTX. It was a defensive check for wilder times when GNU > glibc did not have defines the kernel headers had so rxtx would include > the kernel headers instead. :/ > > If you don't have linux/version.h, it is generated when you configure the > kernel. make oldconfig used to do the trick. It may make sense to work > with the prerelease or CVS code. > > RXTX just assumes that flush, read and anything else the kernel exposes > may be called at anytime from any thread. There isn't a design for the > kernel interaction. There are higher level constraints put in Java to > prevent some things happening at the same time with 'synchronized.' > RXTXPort.java has all of those. > > When the port is opened, a native event thread is started which uses > select to know if an event has happened. > > BSD like systems have a native thread that fires off on write which tries > to flush() to determine when the output buffer is empty asynchronously. > > The rest is not marshaled in any fashion at the native level. T > > I think there is a lower level deadlock being triggered in flush as well. > I don't think it should be possible if everything was right underneath us. > You may want to examine the java code closer to make sure it isnt possible > the lock is there. > > > On Mon, 6 Apr 2009, Bill Johnson wrote: > >> Once it hung, three stack dumps minutes apart were exactly the same. >> I have a noticed that when it hangs, the read appears after flush() enter and >> before flush leave() that doesn't happen like: >> RXTXPort:SerialOutputStream:flush() enter >> RXTXPort:SerialInputStream:read(8192 0 8192) called >> >> When it works, flush() enter and leave happen together. It may just be because >> flush() hangs and read is the only other thread waiting to run at that point. >> I don't know much about the RXTX design and kernel interaction, just digging >> through the code some. Is there a design description somewhere? >> >> Am hung up on target system compile since UTS_RELEASE seems no longer defined for >> 2.6.18 up kernels and have not figured a good patch yet. But, that is another >> issue. >> >> Thanks for the good help. >> >> >> On Fri, Apr 3, 2009 at 6:54 PM, U. George wrote: >> I would have tried 2 or 3 "^\" . If things are stuck, then all will be >> at same 'java' instruction. If thread is moving, then one of the >> snapshots would be different. >> >> I *think* flushing/draining wont return until the kernel buffers to >> device have been accepted by device. Stuck/paused device? >> >> >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From cowwoc at bbs.darktech.org Mon Apr 13 20:41:20 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Mon, 13 Apr 2009 22:41:20 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49E3B6E3.5050203@cox.net> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49E3B6E3.5050203@cox.net> Message-ID: <49E3F7D0.5090207@bbs.darktech.org> Gregg Wonderly wrote: > A PhantomRef is the way to do this kind of cleanup in most cases. It > will always fire. The real issue is that you have to understand that > the on the Sun JVM, the GC can run finalization or advertise a dropped > reference before an object is actually unreferenced in some cases. This > happens, predominately in blocks of code where object references are > short lived with no class member reference that the GC can find. When > the JIT compiled code just references an object on the local stack > and/or a register, the GC can prematurely attempt > finalization/PhantomRef notification and result in bad things happening. I've never seen this myself. Can you reproduce it on the latest JRE? If so, this sounds like a bug to me and should be fixed. Please consider filing a bug report and telling me the bug number. I'll try running it by my Sun contacts. Gili From ferry_new2004 at yahoo.com Mon Apr 13 21:24:59 2009 From: ferry_new2004 at yahoo.com (Ferry Sumendap) Date: Mon, 13 Apr 2009 20:24:59 -0700 (PDT) Subject: [Rxtx] In Linux, RXTX serial port lib cannot send character which hex is more than 127. Message-ID: <30875.39589.qm@web33106.mail.mud.yahoo.com> Hello everybody, I have just tested the RXTXserial port library version RXTX2-1-7pre20 to send two characters which are character ascii 230 and 234. It seems that the driver somehow did not send the two characters into serial port if the Operating System is Linux Mandriva 2007 (kernel version 2.6.17-13mdv ) or Linux Mandriva 2009. I also tried the driver using same java code (java class file of the program I wrote), in Windows XP, it does work. Should I configure something (special configuration in Linux) or did I miss something ? I also have tested the latest RXTX 2.2pre2 driver, but it still have that problem. Regards, Ferry -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090413/94fdfbea/attachment-0004.html From tjarvi at qbang.org Mon Apr 13 22:01:04 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 13 Apr 2009 22:01:04 -0600 (MDT) Subject: [Rxtx] In Linux, RXTX serial port lib cannot send character which hex is more than 127. In-Reply-To: <30875.39589.qm@web33106.mail.mud.yahoo.com> References: <30875.39589.qm@web33106.mail.mud.yahoo.com> Message-ID: On Mon, 13 Apr 2009, Ferry Sumendap wrote: > Hello everybody, > > I have just tested the RXTXserial port library version? RXTX2-1-7pre20 to > send two characters which are character ascii? 230 and 234. It seems that > the driver somehow did not send the two characters into serial port if the > Operating System is Linux Mandriva 2007 (kernel version 2.6.17-13mdv > ) or Linux Mandriva 2009. > I also tried the driver using? same java code (java class file of the > program I wrote), in Windows XP,? it does work. > > Should I configure something (special configuration in Linux)? or did I miss > something ? > I also have tested the latest RXTX 2.2pre2 driver, but it still have that > problem. > Hello Ferry This sounds like an unlikely problem. Even with USB dongle issues, I can't think of a reason that would be a problem. Is this a connection at 9600 8N1? Sometimes it really is the cable. -- Trent Jarvi tjarvi at qbang.org From ferry_new2004 at yahoo.com Mon Apr 13 22:15:04 2009 From: ferry_new2004 at yahoo.com (Ferry Sumendap) Date: Mon, 13 Apr 2009 21:15:04 -0700 (PDT) Subject: [Rxtx] Fw: In Linux, RXTX serial port lib cannot send character which hex is more than 127. Message-ID: <948418.50805.qm@web33103.mail.mud.yahoo.com> ----- Forwarded Message ---- From: Ferry Sumendap To: Trent Jarvi Sent: Tuesday, April 14, 2009 11:10:04 AM Subject: Re: [Rxtx] In Linux, RXTX serial port lib cannot send character which hex is more than 127. Thank you for your answer. I use the same machine, cable and devices to test. My PC is installed with Linux Mandriva and WINDOWS. The serial port physically have no problem since using Windows, it works. I also tested the serial port using MONI (tcl based program). MONI is linux based program to send some characters to serial port. Using MONI, I sent the characters to /dev/ttyS0, and it works because the device which is plugged in /dev/ttyS0 received and answered the message. But for RXTX, some how, java based program cannot send those characters. With the same java based program, it works properly in WINDOWS and the same cable, devices, hardware specification. That's why I am curious about RXTX. Here is the serial port configuration I used. Com Port /dev/ttyS0 Baud rate 19200 Data bits 8 ( value = 8) Stop bits 1 ( value = 1) Parity None ( value = 0) Thank you very much for your response. Regards, Ferry ________________________________ From: Trent Jarvi To: Ferry Sumendap Cc: rxtx at qbang.org Sent: Tuesday, April 14, 2009 11:01:04 AM Subject: Re: [Rxtx] In Linux, RXTX serial port lib cannot send character which hex is more than 127. On Mon, 13 Apr 2009, Ferry Sumendap wrote: > Hello everybody, > > I have just tested the RXTXserial port library version RXTX2-1-7pre20 to > send two characters which are character ascii 230 and 234. It seems that > the driver somehow did not send the two characters into serial port if the > Operating System is Linux Mandriva 2007 (kernel version 2.6.17-13mdv > ) or Linux Mandriva 2009. > I also tried the driver using same java code (java class file of the > program I wrote), in Windows XP, it does work. > > Should I configure something (special configuration in Linux) or did I miss > something ? > I also have tested the latest RXTX 2.2pre2 driver, but it still have that > problem. > Hello Ferry This sounds like an unlikely problem. Even with USB dongle issues, I can't think of a reason that would be a problem. Is this a connection at 9600 8N1? Sometimes it really is the cable. -- Trent Jarvi tjarvi at qbang.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090413/27a37ea5/attachment-0004.html From ferry_new2004 at yahoo.com Mon Apr 13 22:23:53 2009 From: ferry_new2004 at yahoo.com (Ferry Sumendap) Date: Mon, 13 Apr 2009 21:23:53 -0700 (PDT) Subject: [Rxtx] In Linux, RXTX serial port lib cannot send character which hex is more than 127. In-Reply-To: References: <30875.39589.qm@web33106.mail.mud.yahoo.com> <81465.86461.qm@web33102.mail.mud.yahoo.com> Message-ID: <736778.48214.qm@web33108.mail.mud.yahoo.com> I am sorry not telling you about the configuration.. Yes I did test using the same serial port configuration, but the RXTX did not work properly. I also use "root" just in case there is security violation. If I sent another character that is below 127 (ascii < 127) the RXTX works properly either in LINUX or WINDOWS. I also cannot believe that coders of RXTX would make diffentiation between baudrate 19200 and 9600. The driver actually works very good unfortunately if the character is upper than ascii 127 (like ascii 230 and 234) it will not work. Thank you very much. Regards, Ferry ________________________________ From: Trent Jarvi To: Ferry Sumendap Cc: Trent Jarvi Sent: Tuesday, April 14, 2009 11:16:34 AM Subject: Re: [Rxtx] In Linux, RXTX serial port lib cannot send character which hex is more than 127. Hi Ferry, The only thing you mention that is not tested on a regular basis is the 19200 baudrate. There is nothing special (code wise) about that baudrate. On Mon, 13 Apr 2009, Ferry Sumendap wrote: > Thank you for your answer. > > I use the same machine, cable and devices to test. > My PC is installed with Linux Mandriva and WINDOWS. > The serial port physically have no problem since using Windows, it works. > > I also tested the serial port using MONI (tcl based program). > MONI is linux based program to send some characters to serial port. > Using MONI, I sent the characters to /dev/ttyS0, and it works because the > device which is plugged in /dev/ttyS0 received and answered the message. > > But for RXTX, some how, java based program cannot send those characters. > With the same java based program, it works properly in WINDOWS and the same > cable, devices, hardware specification. > That's why I am curious about RXTX. > > > > Here is the serial port configuration I used. > > Com Port /dev/ttyS0 > Baud rate 19200 > Data bits 8 ( value = 8) > Stop bits 1 ( value = 1) > Parity None ( value = 0) > > > > Thank you very much for your response. > > Regards, > Ferry > > > ____________________________________________________________________________ > From: Trent Jarvi > To: Ferry Sumendap > Cc: rxtx at qbang.org > Sent: Tuesday, April 14, 2009 11:01:04 AM > Subject: Re: [Rxtx] In Linux, RXTX serial port lib cannot send character > which hex is more than 127. > > > > On Mon, 13 Apr 2009, Ferry Sumendap wrote: > > > Hello everybody, > > > > I have just tested the RXTXserial port library version RXTX2-1-7pre20 to > > send two characters which are character ascii 230 and 234. It seems that > > the driver somehow did not send the two characters into serial port if the > > Operating System is Linux Mandriva 2007 (kernel version 2.6.17-13mdv > > ) or Linux Mandriva 2009. > > I also tried the driver using same java code (java class file of the > > program I wrote), in Windows XP, it does work. > > > > Should I configure something (special configuration in Linux) or did I > miss > > something ? > > I also have tested the latest RXTX 2.2pre2 driver, but it still have that > > problem. > > > > Hello Ferry > > This sounds like an unlikely problem. > > Even with USB dongle issues, I can't think of a reason that would be a > problem. Is this a connection at 9600 8N1? > > Sometimes it really is the cable. > > -- > Trent Jarvi > tjarvi at qbang.org > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090413/7a2fd5a0/attachment-0004.html From tjarvi at qbang.org Mon Apr 13 22:45:09 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 13 Apr 2009 22:45:09 -0600 (MDT) Subject: [Rxtx] In Linux, RXTX serial port lib cannot send character which hex is more than 127. In-Reply-To: <736778.48214.qm@web33108.mail.mud.yahoo.com> References: <30875.39589.qm@web33106.mail.mud.yahoo.com> <81465.86461.qm@web33102.mail.mud.yahoo.com> <736778.48214.qm@web33108.mail.mud.yahoo.com> Message-ID: This sounds like a signed vs unsigned char issue. Given that rxtx does binary read and write fine on Linux, I'm at a loss of what your problem may be. No, I don't suspect the baudrate is an issue either. On Mon, 13 Apr 2009, Ferry Sumendap wrote: > I am sorry not telling you about the configuration.. > > Yes I did test using the same serial port configuration, but the RXTX did > not work properly. > I also use "root" just in case there is security violation. > If? I sent another character that is below 127 (ascii < 127) the RXTX works > properly either in LINUX or WINDOWS. > > I also cannot believe that coders of RXTX would make diffentiation between > baudrate 19200 and 9600. > The driver actually works very good unfortunately if the character is upper > than ascii 127 (like ascii 230 and 234) it will not work. > > Thank you very much. > Regards, > > Ferry > > ____________________________________________________________________________ > From: Trent Jarvi > To: Ferry Sumendap > Cc: Trent Jarvi > Sent: Tuesday, April 14, 2009 11:16:34 AM > Subject: Re: [Rxtx] In Linux, RXTX serial port lib cannot send character > which hex is more than 127. > > > Hi Ferry, > > The only thing you mention that is not tested on a regular basis is the > 19200 baudrate.? There is nothing special (code wise) about that baudrate. > > On Mon, 13 Apr 2009, Ferry Sumendap wrote: > > > Thank you for your answer. > > > > I use the same machine, cable and devices to test. > > My PC is installed with Linux Mandriva and WINDOWS. > > The serial port physically have no problem since using Windows, it works. > > > > I also tested the serial port using MONI (tcl based program). > > MONI is linux based program to send some characters to serial port. > > Using MONI, I sent the characters to /dev/ttyS0, and it works because the > > device which is plugged in /dev/ttyS0 received and answered the message. > > > > But for RXTX, some how, java based program cannot send those characters. > > With the same java based program, it works properly in WINDOWS and the > same > > cable, devices, hardware specification. > > That's why I am curious about RXTX. > > > > > > > > Here is the serial port configuration I used. > > > > Com Port /dev/ttyS0 > > Baud rate 19200 > > Data bits 8 ( value = 8) > > Stop bits 1?? ( value = 1) > > Parity None? ( value = 0) > > > > > > > > Thank you very much for your response. > > > > Regards, > > Ferry > > > > > >___________________________________________________________________________ > _ > > From: Trent Jarvi > > To: Ferry Sumendap > > Cc: rxtx at qbang.org > > Sent: Tuesday, April 14, 2009 11:01:04 AM > > Subject: Re: [Rxtx] In Linux, RXTX serial port lib cannot send character > > which hex is more than 127. > > > > > > > > On Mon, 13 Apr 2009, Ferry Sumendap wrote: > > > > > Hello everybody, > > > > > > I have just tested the RXTXserial port library version? RXTX2-1-7pre20 > to > > > send two characters which are character ascii? 230 and 234. It seems > that > > > the driver somehow did not send the two characters into serial port if > the > > > Operating System is Linux Mandriva 2007 (kernel version 2.6.17-13mdv > > > ) or Linux Mandriva 2009. > > > I also tried the driver using? same java code (java class file of the > > > program I wrote), in Windows XP,? it does work. > > > > > > Should I configure something (special configuration in Linux)? or did I > > miss > > > something ? > > > I also have tested the latest RXTX 2.2pre2 driver, but it still have > that > > > problem. > > > > > > > Hello Ferry > > > > This sounds like an unlikely problem. > > > > Even with USB dongle issues, I can't think of a reason that would be a > > problem.? Is this a connection at 9600 8N1? > > > > Sometimes it really is the cable. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > > > > > > > > From ilkka at myller.com Mon Apr 13 23:12:16 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 14 Apr 2009 08:12:16 +0300 Subject: [Rxtx] In Linux, RXTX serial port lib cannot send character which hex is more than 127. In-Reply-To: References: <30875.39589.qm@web33106.mail.mud.yahoo.com> <81465.86461.qm@web33102.mail.mud.yahoo.com> <736778.48214.qm@web33108.mail.mud.yahoo.com> Message-ID: Hi, Another suggestion: incorrect java byte casting. Java byte type has a range from -128 to 127. I've seen people assume range of 0 - 255. Incorrect integer casting with bytes is a common mistake is to cause those >127 ascii issues. Could it be? (int)b versus (int)(b & 0xFF) -- I Trent Jarvi kirjoitti 14.4.2009 kello 7.45: > > This sounds like a signed vs unsigned char issue. Given that rxtx > does binary read and write fine on Linux, I'm at a loss of what your > problem may be. > > No, I don't suspect the baudrate is an issue either. > > On Mon, 13 Apr 2009, Ferry Sumendap wrote: > >> I am sorry not telling you about the configuration.. >> Yes I did test using the same serial port configuration, but the >> RXTX did >> not work properly. >> I also use "root" just in case there is security violation. >> If I sent another character that is below 127 (ascii < 127) the >> RXTX works >> properly either in LINUX or WINDOWS. >> I also cannot believe that coders of RXTX would make diffentiation >> between >> baudrate 19200 and 9600. >> The driver actually works very good unfortunately if the character >> is upper >> than ascii 127 (like ascii 230 and 234) it will not work. >> Thank you very much. >> Regards, >> Ferry >> ____________________________________________________________________________ >> From: Trent Jarvi >> To: Ferry Sumendap >> Cc: Trent Jarvi >> Sent: Tuesday, April 14, 2009 11:16:34 AM >> Subject: Re: [Rxtx] In Linux, RXTX serial port lib cannot send >> character >> which hex is more than 127. >> Hi Ferry, >> The only thing you mention that is not tested on a regular basis is >> the >> 19200 baudrate. There is nothing special (code wise) about that >> baudrate. >> On Mon, 13 Apr 2009, Ferry Sumendap wrote: >> > Thank you for your answer. >> > >> > I use the same machine, cable and devices to test. >> > My PC is installed with Linux Mandriva and WINDOWS. >> > The serial port physically have no problem since using Windows, >> it works. >> > >> > I also tested the serial port using MONI (tcl based program). >> > MONI is linux based program to send some characters to serial port. >> > Using MONI, I sent the characters to /dev/ttyS0, and it works >> because the >> > device which is plugged in /dev/ttyS0 received and answered the >> message. >> > >> > But for RXTX, some how, java based program cannot send those >> characters. >> > With the same java based program, it works properly in WINDOWS >> and the >> same >> > cable, devices, hardware specification. >> > That's why I am curious about RXTX. >> > >> > >> > >> > Here is the serial port configuration I used. >> > >> > Com Port /dev/ttyS0 >> > Baud rate 19200 >> > Data bits 8 ( value = 8) >> > Stop bits 1 ( value = 1) >> > Parity None ( value = 0) >> > >> > >> > >> > Thank you very much for your response. >> > >> > Regards, >> > Ferry >> > >> > >> > >> ___________________________________________________________________________ >> _ >> > From: Trent Jarvi >> > To: Ferry Sumendap >> > Cc: rxtx at qbang.org >> > Sent: Tuesday, April 14, 2009 11:01:04 AM >> > Subject: Re: [Rxtx] In Linux, RXTX serial port lib cannot send >> character >> > which hex is more than 127. >> > >> > >> > >> > On Mon, 13 Apr 2009, Ferry Sumendap wrote: >> > >> > > Hello everybody, >> > > >> > > I have just tested the RXTXserial port library version >> RXTX2-1-7pre20 >> to >> > > send two characters which are character ascii 230 and 234. It >> seems >> that >> > > the driver somehow did not send the two characters into serial >> port if >> the >> > > Operating System is Linux Mandriva 2007 (kernel version >> 2.6.17-13mdv >> > > ) or Linux Mandriva 2009. >> > > I also tried the driver using same java code (java class file >> of the >> > > program I wrote), in Windows XP, it does work. >> > > >> > > Should I configure something (special configuration in Linux) >> or did I >> > miss >> > > something ? >> > > I also have tested the latest RXTX 2.2pre2 driver, but it still >> have >> that >> > > problem. >> > > >> > >> > Hello Ferry >> > >> > This sounds like an unlikely problem. >> > >> > Even with USB dongle issues, I can't think of a reason that would >> be a >> > problem. Is this a connection at 9600 8N1? >> > >> > Sometimes it really is the cable. >> > >> > -- >> > Trent Jarvi >> > tjarvi at qbang.org >> > >> > >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From sunil at saltriver.com Tue Apr 14 01:06:38 2009 From: sunil at saltriver.com (Sunil Bhambani) Date: Tue, 14 Apr 2009 07:06:38 -0000 Subject: [Rxtx] RxTx on Mac for USB Message-ID: <1080422816.3127.6.camel@localhost.localdomain> Hi, I have a GPS device which is USB device. I want to use that device on Mac System and Java as the programming language. I have read that USB support through RxTx on Mac is not there. Is this correct? I would like to read the data that comes to GPS device. Can some connector be used to communicate with that device. For example USB to RJ11 or USB to serial connector? Are this connectors reliable enough to be used? Hope to get the reply soon. -- Thank & Regards Sunil -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090414/295ccb1d/attachment-0003.html From helgeingvart at gmail.com Tue Apr 14 01:43:04 2009 From: helgeingvart at gmail.com (Helge Fredriksen) Date: Tue, 14 Apr 2009 09:43:04 +0200 Subject: [Rxtx] IO exceptions on 2.2pre2 In-Reply-To: References: <306B677E-9207-44CB-81CD-787A50DB7DA6@myller.com> Message-ID: FYI: There seem to be success on this problem by switching to your commercial counterpart from SerialIO (http://www.serialio.com). A FTDI only problem? Best regards, Helge Fredriksen On Sat, Mar 28, 2009 at 5:32 PM, Helge Fredriksen wrote: > Thanks for your suggestions, > > We have tried switching off the power saving settings as recommended, but > regrettably we see the same things happening still. > > The FTDI device is not connected directly to USB hubs, no. > > Someone have any more ideas? > > Best regards, > Helge Fredriksen > > > On Tue, Mar 24, 2009 at 9:27 AM, Ilkka Myller wrote: > >> Hi Helge, >> >> I am not sure if this will help, but you could try this: >> >> echo on > /sys/bus/usb/devices//power/level >> echo 0 > /sys/bus/usb/devices//power/autosuspend >> >> is the USB-bus device id of your FTDI adapter (bus-device, for >> example "2-2") >> >> This will disable USB power saving/autosuspend of FTDI USB-device. >> I've seen some some systems where this helps with FTDI-adapter connection >> drops. >> >> Also: is your FTDI device directly connected to PC's USB root hub? If not, >> test that too. >> >> >> -- >> I >> >> (replace with the usb bus device id of your FTDI serial >> adapter) >> >> Helge Fredriksen kirjoitti 24.3.2009 kello 9.45: >> >> Hello! >> >> Here's the device details: >> >> FT232R is a USB to serial UART interface. >> >> Link to componentt: http://www.ftdichip.com/Products/FT232R.htm >> >> Regards, >> Helge Fredriksen >> >> On Tue, Mar 24, 2009 at 12:05 AM, Trent Jarvi wrote: >> >>> >>> >>> On Mon, 23 Mar 2009, Helge Fredriksen wrote: >>> >>> Hello again. >>>> >>>> I'm having a bit trouble with the 2.2pre2 version it seems. I'm having >>>> an >>>> application running on Ubuntu 8.10 that seem to run stable but after an >>>> hour >>>> or so the application breaks down with lot's of IO exceptions like this: >>>> >>>> java.io.IOException: Input/output error in nativeavailable >>>> at gnu.io.RXTXPort.nativeavailable(Native Method) >>>> at gnu.io.RXTXPort$SerialInputStream.available(RXTXPort.java:1596) >>>> >>>> atcom.poseidon.usb.UsbInterface$MySerialPortEventListener.serialEvent(UsbInte >>>> rface.java:251) >>>> at gnu.io.RXTXPort.sendEvent(RXTXPort.java:772) >>>> at gnu.io.RXTXPort.eventLoop(Native Method) >>>> at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1641) >>>> >>>> Any ideas? >>>> >>> >>> Hi Helge, >>> >>> It sounds like the file descriptor (USB driver) is in an invalid state. >>> >>> What can you tell us about the USB dongle? Is it bluetooth? Do you know >>> what chipset is in it? >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090414/e2c97c4f/attachment-0004.html From Steffen.DETTMER at ingenico.com Tue Apr 14 02:21:35 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 14 Apr 2009 10:21:35 +0200 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49E3F7D0.5090207@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49E3B6E3.5050203@cox.net> <49E3F7D0.5090207@bbs.darktech.org> Message-ID: <20090414082135.GG5090@elberon.bln.de.ingenico.com> * cowwoc wrote on Mon, Apr 13, 2009 at 22:41 -0400: > Gregg Wonderly wrote: > > The real issue is that you have to understand that > > the on the Sun JVM, the GC can run finalization or advertise a dropped > > reference before an object is actually unreferenced in some cases. > > I've never seen this myself. Can you reproduce it on the latest JRE? If > so, this sounds like a bug to me and should be fixed. Please consider > filing a bug report and telling me the bug number. I'll try running it > by my Sun contacts. I found some general hints here: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2261.html Traditional finalization in garbage collected languages is defined in terms of object reachability. But objects can easily become "unreachable" earlier than the programmer expects, due to compiler optimizations. An object may be logically in use long past the last point at which the memory associated with the object is accessed or referenced by any pointers visible to the garbage collector. In the worst case, the compiler might decide to store all the fields of an object in registers, and then observe that the "this" pointer for the newly allocated memory is dead immediately after the allocation, and hence not save it anywhere. The garbage collector, even if run immediately after the allocation, would then discover that the memory object is no longer reachable, and run the finalizer immediately, in spite of the fact that the object fields are still in use, and in fact may remain in use after the finalizer has run. However, if this would be a so general weakness that someone is adviced to store object instances in collections instead of using members or having the references on the stack - even if used correctly - I think it would be a major weakness which probably had been fixed, because otherwise raping collections as such workarounds would be commonly visible. BTW, I think the citation above is wrong if the optimised member values are used after that. The destructor / finalizer may set all fields to null or so and (ordinary) optimizers should not affect the behavior of correct and usual code I think. (ohh, and Cowwoc, forced-GC and to forbid the developer to control lifecycle in Java is considered a feature, not a bug! -- SCNR) oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From michael.erskine at ketech.com Tue Apr 14 02:50:53 2009 From: michael.erskine at ketech.com (Michael Erskine) Date: Tue, 14 Apr 2009 09:50:53 +0100 Subject: [Rxtx] Wiki Spam pages - need of captcha? In-Reply-To: References: Message-ID: <06BA3262D918014F9183B66425D5A8D45FA42D88FB@no-sv-03.ketech.local> All, See http://tech.slashdot.org/article.pl?sid=09/04/13/0120226 for details of this particular use of open wiki sites and the apology. Regards, Michael Erskine. From Steffen.DETTMER at ingenico.com Tue Apr 14 04:27:53 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 14 Apr 2009 12:27:53 +0200 Subject: [Rxtx] In Linux, RXTX serial port lib cannot send character which hex is more than 127. In-Reply-To: <30875.39589.qm@web33106.mail.mud.yahoo.com> References: <30875.39589.qm@web33106.mail.mud.yahoo.com> Message-ID: <20090414102753.GI5090@elberon.bln.de.ingenico.com> * Ferry Sumendap wrote on Mon, Apr 13, 2009 at 20:24 -0700: > I have just tested the RXTXserial port library version > RXTX2-1-7pre20 to send two characters which are character ascii > 230 and 234. Can you send -26 and -22 instead? Then it probably is a casting issue (as Trent and Ilkka already considered). oki, Steffen End of message. ------------------------------------------------------------------->8======= About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Bob_Jacobsen at lbl.gov Tue Apr 14 08:31:13 2009 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Tue, 14 Apr 2009 07:31:13 -0700 Subject: [Rxtx] RxTx on Mac for USB In-Reply-To: <1080422816.3127.6.camel@localhost.localdomain> References: <1080422816.3127.6.camel@localhost.localdomain> Message-ID: At 2:56 AM +0530 3/28/04, Sunil Bhambani wrote: >Hi, > >I have a GPS device which is USB device. I want to use that device >on Mac System and Java as the programming language. I have read that >USB support through RxTx on Mac is not there. Is this correct? I >would like to read the data that comes to GPS device. Can some >connector be used to communicate with that device. For example USB >to RJ11 or USB to serial connector? Are this connectors reliable >enough to be used? If the GPS device looks like a serial device to Mac OS X (Darwin), RXTX will work fine. To check: *) Unplug your device. *) Do the following command line, and keep the output: ls -lt /dev/ | head -10 *) Plug in your device and wait a couple seconds *) Repeat the above command line, and see if there are any new entries at the top of the output. The new entries, if any, are how your GPS device was mounted. If the new device(s) start with /dev/tty or /dev/cu, you'll be able to use RXTX. As a next step, you can use the "cu" command to try to talk to your GPS device as serial device. For example, cu -s 19200 -l /dev/tty.usbserial-LWPMMU13 You can download RXTX installers for various MacOS X version from here: But note these are for RXTX 2.0 versions (javax.comm package). Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From sunil at saltriver.com Wed Apr 15 00:06:40 2009 From: sunil at saltriver.com (Sunil Bhambani) Date: Wed, 15 Apr 2009 06:06:40 -0000 Subject: [Rxtx] RxTx on Mac for USB In-Reply-To: References: <1080422816.3127.6.camel@localhost.localdomain> Message-ID: <1080505612.2924.9.camel@localhost.localdomain> On Tue, 2009-04-14 at 07:31 -0700, Bob Jacobsen wrote: > At 2:56 AM +0530 3/28/04, Sunil Bhambani wrote: > >Hi, > > > >I have a GPS device which is USB device. I want to use that device > >on Mac System and Java as the programming language. I have read that > >USB support through RxTx on Mac is not there. Is this correct? I > >would like to read the data that comes to GPS device. Can some > >connector be used to communicate with that device. For example USB > >to RJ11 or USB to serial connector? Are this connectors reliable > >enough to be used? > > If the GPS device looks like a serial device to Mac OS X (Darwin), > RXTX will work fine. > > To check: > > *) Unplug your device. > *) Do the following command line, and keep the output: > > ls -lt /dev/ | head -10 > > *) Plug in your device and wait a couple seconds > > *) Repeat the above command line, and see if there are any new > entries at the top of the output. > > The new entries, if any, are how your GPS device was mounted. If the > new device(s) start with /dev/tty or /dev/cu, you'll be able to use > RXTX. > > As a next step, you can use the "cu" command to try to talk to your > GPS device as serial device. For example, > > cu -s 19200 -l /dev/tty.usbserial-LWPMMU13 > > You can download RXTX installers for various MacOS X version from here: > > > > But note these are for RXTX 2.0 versions (javax.comm package). > > Bob Hi Bob, I am using Mac 10.5 and I have done what you have said. I get the following output total 4 crw--w---- 1 Saltriver tty 16, 0 Apr 15 11:13 ttys000 crw-rw-rw- 1 root wheel 8, 0 Apr 15 11:13 random crw-rw-rw- 1 root tty 15, 1 Apr 15 11:13 ptmx crw------- 1 Saltriver staff 0, 0 Apr 15 11:10 console crw-rw-rw- 1 root wheel 3, 2 Apr 15 10:58 null crw------- 1 root wheel 23, 1 Apr 15 10:32 bpf1 crw------- 1 root wheel 23, 0 Apr 15 10:32 bpf0 crw------- 1 root wheel 11, 0 Apr 15 10:31 autofs crw------- 1 root wheel 17, 0 Apr 15 10:31 autofs_control saltriver-infosystemss-mac-mini:~ Saltriver$ ls -lt /dev/ | head -10 total 4 crw--w---- 1 Saltriver tty 16, 0 Apr 15 11:16 ttys000 crw-rw-rw- 1 root tty 15, 1 Apr 15 11:16 ptmx crw-rw-rw- 1 root wheel 8, 0 Apr 15 11:13 random crw------- 1 Saltriver staff 0, 0 Apr 15 11:10 console crw-rw-rw- 1 root wheel 3, 2 Apr 15 10:58 null crw------- 1 root wheel 23, 1 Apr 15 10:32 bpf1 crw------- 1 root wheel 23, 0 Apr 15 10:32 bpf0 crw------- 1 root wheel 11, 0 Apr 15 10:31 autofs crw------- 1 root wheel 17, 0 Apr 15 10:31 autofs_control I think the output is same in both. Is there any way of mounting that device. I am very new to Mac. I am using RXTX 2.1 without javax.comm package. I have tried the same code in fedora and it ran successfully. I have tried inserting pen drive in the USB port and it was detected. Hope to get a quick reply from you. Thanks & Regards Sunil -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090415/19e599e5/attachment-0002.html From Bob_Jacobsen at lbl.gov Wed Apr 15 03:43:26 2009 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Wed, 15 Apr 2009 02:43:26 -0700 Subject: [Rxtx] RxTx on Mac for USB In-Reply-To: <1080505612.2924.9.camel@localhost.localdomain> References: <1080422816.3127.6.camel@localhost.localdomain> <1080505612.2924.9.camel@localhost.localdomain> Message-ID: At 1:56 AM +0530 3/29/04, Sunil Bhambani wrote: > >I am using Mac 10.5 and I have done what you have said. I get the >following output > >total 4 >crw--w---- 1 Saltriver tty 16, 0 Apr 15 11:13 ttys000 >crw-rw-rw- 1 root wheel 8, 0 Apr 15 11:13 random >crw-rw-rw- 1 root tty 15, 1 Apr 15 11:13 ptmx >crw------- 1 Saltriver staff 0, 0 Apr 15 11:10 console ... >saltriver-infosystemss-mac-mini:~ Saltriver$ ls -lt /dev/ | head -10 >total 4 >crw--w---- 1 Saltriver tty 16, 0 Apr 15 11:16 ttys000 >crw-rw-rw- 1 root tty 15, 1 Apr 15 11:16 ptmx >crw-rw-rw- 1 root wheel 8, 0 Apr 15 11:13 random >crw------- 1 Saltriver staff 0, 0 Apr 15 11:10 console ... >I think the output is same in both. Is there any way of mounting that device. You're going to need a driver of some sort that will make the GPS unit appear as a serial device. > I am very new to Mac. I am using RXTX 2.1 without javax.comm package. This problem is happening before RXTX can do anything at all. Unless there's a device in /dev, RXTX can't even begin to be involved. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From cowwoc at bbs.darktech.org Wed Apr 15 09:08:21 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Wed, 15 Apr 2009 11:08:21 -0400 Subject: [Rxtx] RxTX mentioned on Sun's Java Communications page In-Reply-To: References: Message-ID: <49E5F865.1030206@bbs.darktech.org> >> Looks like RxTx really is the closest thing we have to the 'official' >> implementation. > > Ugh. I don't know of any developer interest in maintaining rxtx 2.0. It > would be cleaner for Sun to just openly take javax.comm for their Sun Ray > project. > > If someone is interested in maintaining rxtx 2.0, don't be afraid to say > so. Just curious, why not have the javax.comm layer just call gnu.io under the hood? This will make require no real work to maintain it even if the underlying implementation keeps on changing. From what I've seen so far the difference between the two APIs is minimal in most places. Gili From Kustaa.Nyholm at planmeca.com Wed Apr 15 09:42:33 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 15 Apr 2009 18:42:33 +0300 Subject: [Rxtx] Java5 support In-Reply-To: <49D7CD82.1040904@bbs.darktech.org> Message-ID: A recent post reminded me of this old thread that I do not think got any replies. Here is my take on the subject (of improving the API): Please do not 'improve' the API! Serial port is an old, simple and mature thing. Let's keep it that way. Very little will be gained by 'improving' it. It is already too bad that Sun spoiled the internals of javax.comm in version 3,0 so that the gnu.io package had to be coined. That is a nuisance but nothing compared to what happens if we start 'improve' the API and make it incompatible with Java Comm API. Even additions should be resisted as this will encourage people to write code that is not compatible with the 'standard' Java Comm API. The world does not need more standards but better compliance to existing standards. If someone feels things like generics/iterators for are needed it is simple to wrap the rxtx or java comm classes into classes to implement these new language features without changing the API. rxtx us great and many thanks and cudos to the maintainers and creators but it is lamentable that something this basic needs to be addressed outside standard JRE. Not to mention being able to do basic USB stuff in Java/std JRE in cross platform deployable fashion. br Kusti > From: cowwoc > Date: Sun, 5 Apr 2009 00:13:38 +0300 > To: > Conversation: [Rxtx] Java5 support > Subject: [Rxtx] Java5 support > > > > Now that you dropped javax.comm support, how about improving the API > by replacing Enumation by Iterator, int by enum, and using Generics? It > would improve the usability of the API. > > Gili > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From cowwoc at bbs.darktech.org Wed Apr 15 11:35:03 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Wed, 15 Apr 2009 13:35:03 -0400 Subject: [Rxtx] YACK Message-ID: <49E61AC7.2060701@bbs.darktech.org> Hi, Please increase the YACK() buffer size from 80 characters to 160. My long paths lead to the following kinds of errors: Error 0x5 at c:\users\gili\documents\rxtx\rxtx-devel\src\termios.c(892): AccessError 0x5 at c:\users\gili\documents\rxtx\rxtx-devel\src\termios.c(892): Access Thanks, Gili From talberts at msiscales.com Wed Apr 15 12:22:20 2009 From: talberts at msiscales.com (Tim Alberts) Date: Wed, 15 Apr 2009 11:22:20 -0700 Subject: [Rxtx] RxTX mentioned on Sun's Java Communications page In-Reply-To: <49E5F865.1030206@bbs.darktech.org> References: <49E5F865.1030206@bbs.darktech.org> Message-ID: <49E625DC.80509@msiscales.com> cowwoc wrote: >>> Looks like RxTx really is the closest thing we have to the 'official' >>> implementation. >>> >> Ugh. I don't know of any developer interest in maintaining rxtx 2.0. It >> would be cleaner for Sun to just openly take javax.comm for their Sun Ray >> project. >> >> If someone is interested in maintaining rxtx 2.0, don't be afraid to say >> so. >> > > Just curious, why not have the javax.comm layer just call gnu.io under > the hood? This will make require no real work to maintain it even if the > underlying implementation keeps on changing. From what I've seen so far > the difference between the two APIs is minimal in most places. > > Gili I can't help but get in on this discussion thread. I starting using javax.comm from Sun and I've got a huge project that is entirely based on it now. Sun dropped support for windows which is a huge disappointment for me. I read Sun's page that if you want serial ports on Java with Windows, go to RXTX. I did this. In my experiments I've found by trial and error (and by discussion on this list) that under the hood, Sun javax.comm and RXTX gnu.io are completely different. So since Sun doesn't care about anyone who doesn't use their platforms (or at least anyone that uses Windows). I would argue that RXTX has no obligation to Sun. On another note, I have yet to see (or get) RXTX to work in my code that works perfectly fine using the old Sun javax.comm for windows binaries that I am forced to continue to run on. -------------- next part -------------- A non-text attachment was scrubbed... Name: talberts.vcf Type: text/x-vcard Size: 337 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20090415/a373e7f2/attachment-0002.vcf From cowwoc at bbs.darktech.org Wed Apr 15 13:13:03 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Wed, 15 Apr 2009 15:13:03 -0400 Subject: [Rxtx] Java5 support In-Reply-To: References: Message-ID: <49E631BF.9040501@bbs.darktech.org> > > A recent post reminded me of this old thread that I do not think got any > replies. > > Here is my take on the subject (of improving the API): > > Please do not 'improve' the API! > > Serial port is an old, simple and mature thing. Let's keep it that way. > Very little will be gained by 'improving' it. It is already too bad > that Sun spoiled the internals of javax.comm in version 3,0 so that the > gnu.io package had to be coined. That is a nuisance but nothing compared to > what happens if we start 'improve' the API and make it incompatible with > Java Comm API. > > Even additions should be resisted as this will encourage people to write > code that is not compatible with the 'standard' Java Comm API. The world > does not need more standards but better compliance to existing standards. > > If someone feels things like generics/iterators for are needed it is simple > to wrap the rxtx or java comm classes into classes to implement these > new language features without changing the API. > > rxtx us great and many thanks and cudos to the maintainers and creators but > it is lamentable that something this basic needs to be addressed outside > standard JRE. Not to mention being able to do basic USB stuff in Java/std > JRE in cross platform deployable fashion. > > br Kusti Hi Kusti, I must be missing something... I thought the entire point of forking off gnu.io was to innovate the API in a different direction than javax.comm, otherwise why wouldn't you stick to the standard API? Thanks, Gili From cowwoc at bbs.darktech.org Wed Apr 15 14:57:46 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Wed, 15 Apr 2009 16:57:46 -0400 Subject: [Rxtx] Timeout patch Message-ID: <49E64A4A.1050806@bbs.darktech.org> Hi, Please review the attached patch. - fixes disableReceiveTimeout() so reads now block until data is available. - receive timeouts and threshold handling is now more consistent across all implementations Gili -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: timeout.patch Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20090415/6815e522/attachment-0002.pl From bschlining at gmail.com Wed Apr 15 17:15:10 2009 From: bschlining at gmail.com (Brian Schlining) Date: Wed, 15 Apr 2009 16:15:10 -0700 Subject: [Rxtx] Timeout patch In-Reply-To: <49E64A4A.1050806@bbs.darktech.org> References: <49E64A4A.1050806@bbs.darktech.org> Message-ID: > > - fixes disableReceiveTimeout() so reads now block until data is available. Finally!! Thanks for submitting this patch. Hopefully it'll be integrated soon. Cheers -- B ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090415/a4143da7/attachment-0002.html From tristan.dyer at cgi.com Wed Apr 15 17:32:43 2009 From: tristan.dyer at cgi.com (Dyer, Tristan) Date: Wed, 15 Apr 2009 19:32:43 -0400 Subject: [Rxtx] Java5 support In-Reply-To: <49E631BF.9040501@bbs.darktech.org> References: <49E631BF.9040501@bbs.darktech.org> Message-ID: <9DA32B4D8579AF44AD96C1CC2E9C518D0346E9EB@MTL-MSG-02.cgiclients.com> That's weird. All I had to do to get my project running on RxTx was to change javax.comm to gnu.io I assume the reason for the fork to gnu.io was precisely to preserve compatibility with javax.comm. Unless Sun is willing to give you a TCK (or someone wants to pay for it) you wouldn't be able to provide any of the "new" javax.comm 3.0 feature set to windows and call it javax.comm, and as a side effect you get to keep the api consistent across platforms as well. Apache has been in a pissing fight with Sun for a couple years about this in regards to Harmony. As I remember rxtx was a lower level that suns CommAPI jar could talk to, to provide javax.comm on linux originally. With sun only providing CommAPI for some environments it became necessary to fork. At least that's how I assume it got here. Tristan -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of cowwoc Sent: Wednesday, April 15, 2009 4:13 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Java5 support > > A recent post reminded me of this old thread that I do not think got any > replies. > > Here is my take on the subject (of improving the API): > > Please do not 'improve' the API! > > Serial port is an old, simple and mature thing. Let's keep it that way. > Very little will be gained by 'improving' it. It is already too bad > that Sun spoiled the internals of javax.comm in version 3,0 so that the > gnu.io package had to be coined. That is a nuisance but nothing compared to > what happens if we start 'improve' the API and make it incompatible with > Java Comm API. > > Even additions should be resisted as this will encourage people to write > code that is not compatible with the 'standard' Java Comm API. The world > does not need more standards but better compliance to existing standards. > > If someone feels things like generics/iterators for are needed it is simple > to wrap the rxtx or java comm classes into classes to implement these > new language features without changing the API. > > rxtx us great and many thanks and cudos to the maintainers and creators but > it is lamentable that something this basic needs to be addressed outside > standard JRE. Not to mention being able to do basic USB stuff in Java/std > JRE in cross platform deployable fashion. > > br Kusti Hi Kusti, I must be missing something... I thought the entire point of forking off gnu.io was to innovate the API in a different direction than javax.comm, otherwise why wouldn't you stick to the standard API? Thanks, Gili _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Apr 15 17:48:20 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 15 Apr 2009 17:48:20 -0600 (MDT) Subject: [Rxtx] Timeout patch In-Reply-To: <49E64A4A.1050806@bbs.darktech.org> References: <49E64A4A.1050806@bbs.darktech.org> Message-ID: On Wed, 15 Apr 2009, cowwoc wrote: > Hi, > > Please review the attached patch. > > - fixes disableReceiveTimeout() so reads now block until data is available. > - receive timeouts and threshold handling is now more consistent across all > implementations > Hi Gili, This looks good to me. One 'minor' issue is that you are returning -1 instead of 0 now on timeout. It is fair to say timeouts are the same as the end of input but that is new behavior in rxtx we should warn existing users about so they can adjust their code. -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Wed Apr 15 17:52:46 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Wed, 15 Apr 2009 19:52:46 -0400 Subject: [Rxtx] Timeout patch In-Reply-To: References: <49E64A4A.1050806@bbs.darktech.org> Message-ID: <49E6734E.4010809@bbs.darktech.org> Actually returning -1 on timeout would be bug on my part. I believe that InputStream is expecting us to return 0 in such a case. Which part of my patch changes the return value? Thanks, Gili Trent Jarvi wrote: > On Wed, 15 Apr 2009, cowwoc wrote: > >> Hi, >> >> Please review the attached patch. >> >> - fixes disableReceiveTimeout() so reads now block until data is >> available. >> - receive timeouts and threshold handling is now more consistent >> across all implementations >> > > Hi Gili, > > This looks good to me. One 'minor' issue is that you are returning -1 > instead of 0 now on timeout. It is fair to say timeouts are the same as > the end of input but that is new behavior in rxtx we should warn > existing users about so they can adjust their code. > > -- > Trent Jarvi > tjarvi at qbang.org > From tjarvi at qbang.org Wed Apr 15 18:38:01 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 15 Apr 2009 18:38:01 -0600 (MDT) Subject: [Rxtx] Java5 support In-Reply-To: <9DA32B4D8579AF44AD96C1CC2E9C518D0346E9EB@MTL-MSG-02.cgiclients.com> References: <49E631BF.9040501@bbs.darktech.org> <9DA32B4D8579AF44AD96C1CC2E9C518D0346E9EB@MTL-MSG-02.cgiclients.com> Message-ID: The project isn't interested in breaking projects or changing the API. That said, we do allow some extensions to be added that are clearly marked as such. These extensions are all in the weird science category - they are not alternatives to doing what the API can already do or even something many people would want to use some of the time. The gnu.io namespace is used to avoid polluting of the javax.comm namespace. There are a number of reasons why we could be concerned about using javax.comm including political and/or legal questions but the main reason is a project like rxtx should do no harm. On Wed, 15 Apr 2009, Dyer, Tristan wrote: > That's weird. > > All I had to do to get my project running on RxTx was to change > javax.comm to gnu.io > > I assume the reason for the fork to gnu.io was precisely to preserve > compatibility with javax.comm. Unless Sun is willing to give you a TCK > (or someone wants to pay for it) you wouldn't be able to provide any of > the "new" javax.comm 3.0 feature set to windows and call it javax.comm, > and as a side effect you get to keep the api consistent across platforms > as well. Apache has been in a pissing fight with Sun for a couple years > about this in regards to Harmony. > > As I remember rxtx was a lower level that suns CommAPI jar could talk > to, to provide javax.comm on linux originally. With sun only providing > CommAPI for some environments it became necessary to fork. > > At least that's how I assume it got here. > > Tristan > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > Of cowwoc > Sent: Wednesday, April 15, 2009 4:13 PM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Java5 support > >> >> A recent post reminded me of this old thread that I do not think got > any >> replies. >> >> Here is my take on the subject (of improving the API): >> >> Please do not 'improve' the API! >> >> Serial port is an old, simple and mature thing. Let's keep it that > way. >> Very little will be gained by 'improving' it. It is already too bad >> that Sun spoiled the internals of javax.comm in version 3,0 so that > the >> gnu.io package had to be coined. That is a nuisance but nothing > compared to >> what happens if we start 'improve' the API and make it incompatible > with >> Java Comm API. >> >> Even additions should be resisted as this will encourage people to > write >> code that is not compatible with the 'standard' Java Comm API. The > world >> does not need more standards but better compliance to existing > standards. >> >> If someone feels things like generics/iterators for are needed it is > simple >> to wrap the rxtx or java comm classes into classes to implement these >> new language features without changing the API. >> >> rxtx us great and many thanks and cudos to the maintainers and > creators but >> it is lamentable that something this basic needs to be addressed > outside >> standard JRE. Not to mention being able to do basic USB stuff in > Java/std >> JRE in cross platform deployable fashion. >> >> br Kusti > > Hi Kusti, > > I must be missing something... I thought the entire point of forking > > off gnu.io was to innovate the API in a different direction than > javax.comm, otherwise why wouldn't you stick to the standard API? > > Thanks, > Gili > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Wed Apr 15 18:53:42 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 15 Apr 2009 18:53:42 -0600 (MDT) Subject: [Rxtx] Timeout patch In-Reply-To: <49E6734E.4010809@bbs.darktech.org> References: <49E64A4A.1050806@bbs.darktech.org> <49E6734E.4010809@bbs.darktech.org> Message-ID: Hi Gili, I guess the documentation just needs to be clear and consistant (which it really wasn't before). This is what caught my eye but looking above it, I see the previous documentation mentions -1 in places too. -*timeout threshold Behavior -*------------------------------------------------------------------------ -*0 0 blocks until 1 byte is available -*>0 0 blocks until timeout occurs, returns 0 on timeout -*>0 >0 blocks until timeout or reads threshold bytes, - returns 0 on timeout -*0 >0 blocks until reads threshold bytes - */ + * timeout threshold Behavior + * --------------------------------------------------------------------------- + * < 0 <= 0 blocks until any data is available. + * < 0 > 0 blocks until {@code min(threshold, b.len)} bytes are available. + * >=0 <=0 blocks for {@code timeout} ms or until any data is available. Returns -1 on timeout. + * >=0 > 0 blocks for {@code timeout} ms or until {@code min(threshold, b.len)} bytes are available. Returns -1 on timeout. On Wed, 15 Apr 2009, cowwoc wrote: > > Actually returning -1 on timeout would be bug on my part. I believe > that InputStream is expecting us to return 0 in such a case. Which part of my > patch changes the return value? > > Thanks, > Gili > > Trent Jarvi wrote: >> On Wed, 15 Apr 2009, cowwoc wrote: >> >>> Hi, >>> >>> Please review the attached patch. >>> >>> - fixes disableReceiveTimeout() so reads now block until data is >>> available. >>> - receive timeouts and threshold handling is now more consistent across >>> all implementations >>> >> >> Hi Gili, >> >> This looks good to me. One 'minor' issue is that you are returning -1 >> instead of 0 now on timeout. It is fair to say timeouts are the same as >> the end of input but that is new behavior in rxtx we should warn existing >> users about so they can adjust their code. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> > From cowwoc at bbs.darktech.org Wed Apr 15 19:26:28 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Wed, 15 Apr 2009 21:26:28 -0400 Subject: [Rxtx] Timeout patch In-Reply-To: References: <49E64A4A.1050806@bbs.darktech.org> <49E6734E.4010809@bbs.darktech.org> Message-ID: <49E68944.3050808@bbs.darktech.org> Hi Trent, Please modify the Javadoc to read that timeouts will return 0. PS: The rxtx source contains plenty of ... questionable ... lines of code. The following items come to mind: 1) In serial_read() we return -1 on various error codes instead of throwing the appropriate exception back into the Java layer. 2) Some Java methods print error messages to stdout instead of throwing exceptions on invalid input. 3) #ifdef LIFE_IS_GOOD (is this ever used?) and "/* Baby did a bad baad thing */". Ifdef and comments like this litter the code. 4) Most files use C-language instead of C++. I am not advocating fancy C++ but rather C code wrapped in objects. Moving variable declarations closer to their usage and perhaps grouping related methods into cohesive classes would improve readability. I know this is an open-source project, but the quality of the code freaks me out :) Is there any resistance to fixing some of these problems? Gili Trent Jarvi wrote: > > Hi Gili, > > I guess the documentation just needs to be clear and consistant (which > it really wasn't before). This is what caught my eye but looking > above it, I see the previous documentation mentions -1 in places too. > > -*timeout threshold Behavior > -*------------------------------------------------------------------------ > > -*0 0 blocks until 1 byte is available > -*>0 0 blocks until timeout occurs, returns 0 on timeout > -*>0 >0 blocks until timeout or reads threshold bytes, > - returns 0 on timeout > -*0 >0 blocks until reads threshold bytes > - */ > + * timeout threshold Behavior > + * > --------------------------------------------------------------------------- > > + * < 0 <= 0 blocks until any data is available. > + * < 0 > 0 blocks until {@code min(threshold, > b.len)} bytes are available. > + * >=0 <=0 blocks for {@code timeout} ms or until > any data is available. Returns -1 on timeout. > + * >=0 > 0 blocks for {@code timeout} ms or until > {@code min(threshold, b.len)} bytes are available. Returns -1 on timeout. > > > > On Wed, 15 Apr 2009, cowwoc wrote: > >> >> Actually returning -1 on timeout would be bug on my part. I >> believe that InputStream is expecting us to return 0 in such a case. >> Which part of my patch changes the return value? >> >> Thanks, >> Gili >> >> Trent Jarvi wrote: >>> On Wed, 15 Apr 2009, cowwoc wrote: >>> >>>> Hi, >>>> >>>> Please review the attached patch. >>>> >>>> - fixes disableReceiveTimeout() so reads now block until data is >>>> available. >>>> - receive timeouts and threshold handling is now more consistent >>>> across all implementations >>>> >>> >>> Hi Gili, >>> >>> This looks good to me. One 'minor' issue is that you are returning >>> -1 instead of 0 now on timeout. It is fair to say timeouts are the >>> same as the end of input but that is new behavior in rxtx we should >>> warn existing users about so they can adjust their code. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >> From cowwoc at bbs.darktech.org Wed Apr 15 19:30:08 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Wed, 15 Apr 2009 21:30:08 -0400 Subject: [Rxtx] Java5 support In-Reply-To: References: <49E631BF.9040501@bbs.darktech.org> <9DA32B4D8579AF44AD96C1CC2E9C518D0346E9EB@MTL-MSG-02.cgiclients.com> Message-ID: <49E68A20.80209@bbs.darktech.org> Trent Jarvi wrote: > The project isn't interested in breaking projects or changing the API. > That said, we do allow some extensions to be added that are clearly marked > as such. These extensions are all in the weird science category - they > are not alternatives to doing what the API can already do or even > something many people would want to use some of the time. We could define rxtx-specific classes in gnu.io that extend those in javax.comm so users would enjoy both backwards compatibility as well as rxtx-specific extensions. > The gnu.io namespace is used to avoid polluting of the javax.comm > namespace. There are a number of reasons why we could be concerned about > using javax.comm including political and/or legal questions but the main > reason is a project like rxtx should do no harm. Did anyone from Sun \take issue with the aforementioned approach (gnu.io extending javax.comm)? Gili > On Wed, 15 Apr 2009, Dyer, Tristan wrote: > >> That's weird. >> >> All I had to do to get my project running on RxTx was to change >> javax.comm to gnu.io >> >> I assume the reason for the fork to gnu.io was precisely to preserve >> compatibility with javax.comm. Unless Sun is willing to give you a TCK >> (or someone wants to pay for it) you wouldn't be able to provide any of >> the "new" javax.comm 3.0 feature set to windows and call it javax.comm, >> and as a side effect you get to keep the api consistent across platforms >> as well. Apache has been in a pissing fight with Sun for a couple years >> about this in regards to Harmony. >> >> As I remember rxtx was a lower level that suns CommAPI jar could talk >> to, to provide javax.comm on linux originally. With sun only providing >> CommAPI for some environments it became necessary to fork. >> >> At least that's how I assume it got here. >> >> Tristan >> >> >> -----Original Message----- >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >> Of cowwoc >> Sent: Wednesday, April 15, 2009 4:13 PM >> To: rxtx at qbang.org >> Subject: Re: [Rxtx] Java5 support >> >>> A recent post reminded me of this old thread that I do not think got >> any >>> replies. >>> >>> Here is my take on the subject (of improving the API): >>> >>> Please do not 'improve' the API! >>> >>> Serial port is an old, simple and mature thing. Let's keep it that >> way. >>> Very little will be gained by 'improving' it. It is already too bad >>> that Sun spoiled the internals of javax.comm in version 3,0 so that >> the >>> gnu.io package had to be coined. That is a nuisance but nothing >> compared to >>> what happens if we start 'improve' the API and make it incompatible >> with >>> Java Comm API. >>> >>> Even additions should be resisted as this will encourage people to >> write >>> code that is not compatible with the 'standard' Java Comm API. The >> world >>> does not need more standards but better compliance to existing >> standards. >>> If someone feels things like generics/iterators for are needed it is >> simple >>> to wrap the rxtx or java comm classes into classes to implement these >>> new language features without changing the API. >>> >>> rxtx us great and many thanks and cudos to the maintainers and >> creators but >>> it is lamentable that something this basic needs to be addressed >> outside >>> standard JRE. Not to mention being able to do basic USB stuff in >> Java/std >>> JRE in cross platform deployable fashion. >>> >>> br Kusti >> Hi Kusti, >> >> I must be missing something... I thought the entire point of forking >> >> off gnu.io was to innovate the API in a different direction than >> javax.comm, otherwise why wouldn't you stick to the standard API? >> >> Thanks, >> Gili >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Apr 15 20:19:01 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 15 Apr 2009 20:19:01 -0600 (MDT) Subject: [Rxtx] Timeout patch In-Reply-To: <49E68944.3050808@bbs.darktech.org> References: <49E64A4A.1050806@bbs.darktech.org> <49E6734E.4010809@bbs.darktech.org> <49E68944.3050808@bbs.darktech.org> Message-ID: Hi Gili, Your glowing review obviously means you have not read termios.c :) I'm not against the type of changes like you suggest. I do think they will need bake time and we have people waiting for what we have now. Putting proactive changes in the following release would be fine. The returning -1 issues are wrong and should be fixed. We can do that now. Regarding C/C++, I think the best thing to do for this project is push as much logic as is possible out of the C files and into Java. Use Java for the objects and C to perform as little as possible. This is a compromise in a sense; C++ is perfectly fine and would work. C++ could even be easier to read and probably would avoid some bugs - especial with C strings. I really don't want to build g++ cross compilers for all the platforms we do in the ToyBox. In practice, adding g++ into the mix is an order of magnitude harder to get working. If we can avoid using C++ completely, there is a measurable advantage in what we can easily deliver. http://rxtx.qbang.org//ToyBox Proof of concept: http://rxtx.qbang.org/ToyBox/2.1-7-build1/Linux/glibc-2.3.5/ On Wed, 15 Apr 2009, cowwoc wrote: > Hi Trent, > > Please modify the Javadoc to read that timeouts will return 0. > > PS: The rxtx source contains plenty of ... questionable ... lines of code. > The following items come to mind: > > 1) In serial_read() we return -1 on various error codes instead of throwing > the appropriate exception back into the Java layer. > 2) Some Java methods print error messages to stdout instead of throwing > exceptions on invalid input. > 3) #ifdef LIFE_IS_GOOD (is this ever used?) and "/* Baby did a bad baad > thing */". Ifdef and comments like this litter the code. > 4) Most files use C-language instead of C++. I am not advocating fancy C++ > but rather C code wrapped in objects. Moving variable declarations closer to > their usage and perhaps grouping related methods into cohesive classes would > improve readability. > > I know this is an open-source project, but the quality of the code > freaks me out :) Is there any resistance to fixing some of these problems? > > Gili > > Trent Jarvi wrote: >> >> Hi Gili, >> >> I guess the documentation just needs to be clear and consistant (which it >> really wasn't before). This is what caught my eye but looking above it, I >> see the previous documentation mentions -1 in places too. >> >> -*timeout threshold Behavior >> -*------------------------------------------------------------------------ >> -*0 0 blocks until 1 byte is available >> -*>0 0 blocks until timeout occurs, returns 0 on timeout >> -*>0 >0 blocks until timeout or reads threshold bytes, >> - returns 0 on timeout >> -*0 >0 blocks until reads threshold bytes >> - */ >> + * timeout threshold Behavior >> + * >> --------------------------------------------------------------------------- >> + * < 0 <= 0 blocks until any data is available. >> + * < 0 > 0 blocks until {@code min(threshold, b.len)} >> bytes are available. >> + * >=0 <=0 blocks for {@code timeout} ms or until any >> data is available. Returns -1 on timeout. >> + * >=0 > 0 blocks for {@code timeout} ms or until {@code >> min(threshold, b.len)} bytes are available. Returns -1 on timeout. >> >> >> >> On Wed, 15 Apr 2009, cowwoc wrote: >> >>> >>> Actually returning -1 on timeout would be bug on my part. I believe >>> that InputStream is expecting us to return 0 in such a case. Which part of >>> my patch changes the return value? >>> >>> Thanks, >>> Gili >>> >>> Trent Jarvi wrote: >>>> On Wed, 15 Apr 2009, cowwoc wrote: >>>> >>>>> Hi, >>>>> >>>>> Please review the attached patch. >>>>> >>>>> - fixes disableReceiveTimeout() so reads now block until data is >>>>> available. >>>>> - receive timeouts and threshold handling is now more consistent across >>>>> all implementations >>>>> >>>> >>>> Hi Gili, >>>> >>>> This looks good to me. One 'minor' issue is that you are returning -1 >>>> instead of 0 now on timeout. It is fair to say timeouts are the same as >>>> the end of input but that is new behavior in rxtx we should warn existing >>>> users about so they can adjust their code. >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> >>> > From tjarvi at qbang.org Wed Apr 15 21:38:29 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 15 Apr 2009 21:38:29 -0600 (MDT) Subject: [Rxtx] Java5 support In-Reply-To: <49E68A20.80209@bbs.darktech.org> References: <49E631BF.9040501@bbs.darktech.org> <9DA32B4D8579AF44AD96C1CC2E9C518D0346E9EB@MTL-MSG-02.cgiclients.com> <49E68A20.80209@bbs.darktech.org> Message-ID: On Wed, 15 Apr 2009, cowwoc wrote: > Trent Jarvi wrote: >> The project isn't interested in breaking projects or changing the API. That >> said, we do allow some extensions to be added that are clearly marked as >> such. These extensions are all in the weird science category - they are >> not alternatives to doing what the API can already do or even something >> many people would want to use some of the time. > > We could define rxtx-specific classes in gnu.io that extend those in > javax.comm so users would enjoy both backwards compatibility as well as > rxtx-specific extensions. > >> The gnu.io namespace is used to avoid polluting of the javax.comm >> namespace. There are a number of reasons why we could be concerned about >> using javax.comm including political and/or legal questions but the main >> reason is a project like rxtx should do no harm. > > Did anyone from Sun \take issue with the aforementioned approach > (gnu.io extending javax.comm)? > It would take more than an opinion from someone at Sun before we moved like that. javax.comm (a namespace grandfathered into the JSR) is a broken namespace with a special 'generic' legacy release that may be discontinued at any time. The people using rxtx are interested in what javax.comm was in version 2.0. Not the 3.0 currently offered which appears to be a quick fix for a business need Sun satisfied on Solaris. Why would we ever depend upon (extend) this namespace? -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Thu Apr 16 10:38:42 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Thu, 16 Apr 2009 12:38:42 -0400 Subject: [Rxtx] Java5 support In-Reply-To: References: <49E631BF.9040501@bbs.darktech.org> <9DA32B4D8579AF44AD96C1CC2E9C518D0346E9EB@MTL-MSG-02.cgiclients.com> <49E68A20.80209@bbs.darktech.org> Message-ID: <49E75F12.7010603@bbs.darktech.org> Trent Jarvi wrote: > It would take more than an opinion from someone at Sun before we moved > like that. > > javax.comm (a namespace grandfathered into the JSR) is a broken > namespace with a special 'generic' legacy release that may be > discontinued at any time. The people using rxtx are interested in what > javax.comm was in version 2.0. Not the 3.0 currently offered which > appears to be a quick fix for a business need Sun satisfied on Solaris. > > Why would we ever depend upon (extend) this namespace? I was under the impression that javax.comm 3.0 was backwards compatible against 2.0... What changes in 3.0 do the rxtx folk object to? The way I see it, gnu.io suffers from the following pain points: 1) Not backwards compatible with standard API 2) Non-existent Javadoc for most of the API 3) Tiny community base, non-existent commercial support, questionable code quality. I still don't understand enough about the reasoning behind the namespace fork. I'm all for forking if we take the opportunity to innovate the API, but if you're going to keep it almost identical I'd be in favor of just having gnu.io extend javax.comm. Again, I might change my mind once I understand your reasoning better but that's how I feel now. Gili From bschlining at gmail.com Thu Apr 16 12:04:05 2009 From: bschlining at gmail.com (Brian Schlining) Date: Thu, 16 Apr 2009 11:04:05 -0700 Subject: [Rxtx] Java5 support In-Reply-To: <49E75F12.7010603@bbs.darktech.org> References: <49E631BF.9040501@bbs.darktech.org> <9DA32B4D8579AF44AD96C1CC2E9C518D0346E9EB@MTL-MSG-02.cgiclients.com> <49E68A20.80209@bbs.darktech.org> <49E75F12.7010603@bbs.darktech.org> Message-ID: > > > I was under the impression that javax.comm 3.0 was backwards > compatible > against 2.0... What changes in 3.0 do the rxtx folk object to? I haven't tried 3.0, since my target platforms are usually Mac or Windows. I can say that when Sun dropped Windows support of Javacomm, it was quite a slap in the face. The real kicker was that they removed the downloads for version 2.0 too. So that left folks who were using Sun's API in a pickle. > > The way I see it, gnu.io suffers from the following pain points: > > 1) Not backwards compatible with standard API Hmmm, not exactly true. When Sun removed Javacomm 2.0, RXTX was a real savior, I only had to change the namespace in my code and everything worked. > 2) Non-existent Javadoc for most of the API Sort of. Since RXTX's API is the same as Sun's, code examples and Javadocs from Sun's stuff do apply to RXTX. > 3) Tiny community base, non-existent commercial support, questionable > code quality. You really should back those assertions up with facts before make them. I can think of a number of projects here at my employer that use RXTX, so we really appreciate Trent's work as well as all the folks who have contributed patches. If you want commercial support I'm sure that if you offered enough money, Trent would work something out with you ;-). Also, there's always http://serialio.com/products/serialport/serialport.php As to the code quality, the project is open source, feel free to contribute fixes. > I still don't understand enough about the reasoning behind the > namespace fork. I'm all for forking if we take the opportunity to > innovate the API, but if you're going to keep it almost identical I'd be > in favor of just having gnu.io extend javax.comm. Again, I might change > my mind once I understand your reasoning better but that's how I feel now. > As to extending/innovating the API, RXTX is an open-source project. You can always take the code base and fork it to suit your needs, as long as you adhere to the LGPL license. Cheers -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090416/32cb4447/attachment.html From paul at cometway.com Thu Apr 16 12:56:35 2009 From: paul at cometway.com (Paul Cunningham) Date: Thu, 16 Apr 2009 14:56:35 -0400 Subject: [Rxtx] Java5 support Message-ID: <91BF244D-07E4-4B30-9F9D-0DC0964045B4@cometway.com> I've been a steady lurker on this board for years and have to agree with Brian here: 1) RXTX was a savior -- long before javax.comm was dropped from Sun's repertoire. For Mac OS X users it's the ONLY option. Serial port support on the Mac has always been a sore spot for me. 2) There's nothing complicated about the javax.comm APIs and they are well Javadoc'ed all over the web. RXTX adherence to them has been very consistent. 3) RS-232 with Java is a tiny community period. If you are reading this, I'm sorry but you are a freak. Anyone doing RS-232 for unknown device "x" is a member of an even tinier community with practically no support whatsoever. However this RXTX list community is extremely well supported and every important question is addressed quickly, personally and in great detail by Trent himself. You can't get support like that from most "commercial" operations and we certainly never got that from commercial entities like Sun. Nobody here is going to hold your hand, but we will point you to any available resources that aren't already clearly spelled out on the RXTX page. You might have to learn how to download and build the package for yourself to get the latest updates and fixes, but that's just par for the course. -pc On Apr 16, 2009, at 2:04 PM, Brian Schlining wrote: > > I was under the impression that javax.comm 3.0 was backwards > compatible > against 2.0... What changes in 3.0 do the rxtx folk object to? > > I haven't tried 3.0, since my target platforms are usually Mac or > Windows. I can say that when Sun dropped Windows support of > Javacomm, it was quite a slap in the face. The real kicker was that > they removed the downloads for version 2.0 too. So that left folks > who were using Sun's API in a pickle. > > > The way I see it, gnu.io suffers from the following pain > points: > > 1) Not backwards compatible with standard API > > Hmmm, not exactly true. When Sun removed Javacomm 2.0, RXTX was a > real savior, I only had to change the namespace in my code and > everything worked. > > 2) Non-existent Javadoc for most of the API > > Sort of. Since RXTX's API is the same as Sun's, code examples and > Javadocs from Sun's stuff do apply to RXTX. > > 3) Tiny community base, non-existent commercial support, questionable > code quality. > > You really should back those assertions up with facts before make > them. > > I can think of a number of projects here at my employer that use > RXTX, so we really appreciate Trent's work as well as all the folks > who have contributed patches. If you want commercial support I'm > sure that if you offered enough money, Trent would work something > out with you ;-). Also, there's always http://serialio.com/products/serialport/serialport.php > > As to the code quality, the project is open source, feel free to > contribute fixes. > > I still don't understand enough about the reasoning behind the > namespace fork. I'm all for forking if we take the opportunity to > innovate the API, but if you're going to keep it almost identical > I'd be > in favor of just having gnu.io extend javax.comm. Again, I might > change > my mind once I understand your reasoning better but that's how I > feel now. > > As to extending/innovating the API, RXTX is an open-source project. > You can always take the code base and fork it to suit your needs, as > long as you adhere to the LGPL license. > > Cheers > > -- > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > Brian Schlining > bschlining at gmail.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090416/dd8eda0b/attachment.html From cowwoc at bbs.darktech.org Thu Apr 16 14:07:41 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Thu, 16 Apr 2009 16:07:41 -0400 Subject: [Rxtx] Java5 support In-Reply-To: <91BF244D-07E4-4B30-9F9D-0DC0964045B4@cometway.com> References: <91BF244D-07E4-4B30-9F9D-0DC0964045B4@cometway.com> Message-ID: <49E7900D.3060100@bbs.darktech.org> Paul Cunningham wrote: > 2) There's nothing complicated about the javax.comm APIs and they are > well Javadoc'ed all over the web. RXTX adherence to them has been very > consistent. The fact that javax.comm has good Javadoc does not mean that gnu.io does. The latter has little or no Javadoc. Yes we could assume that gnu.io's documentation is identical to javax.comm but the fact remains that code-completion won't bring up Javadoc for gnu.io. Secondly, someone mentioned recently that although the APIs are supposed to be the same, RXTX in fact behaves noticeably different from javax.comm. The gnu.io specification needs to be nailed down one way or the other. Gili From bschlining at gmail.com Thu Apr 16 14:25:38 2009 From: bschlining at gmail.com (Brian Schlining) Date: Thu, 16 Apr 2009 13:25:38 -0700 Subject: [Rxtx] Java5 support In-Reply-To: <49E7900D.3060100@bbs.darktech.org> References: <91BF244D-07E4-4B30-9F9D-0DC0964045B4@cometway.com> <49E7900D.3060100@bbs.darktech.org> Message-ID: > > The fact that javax.comm has good Javadoc does not mean that gnu.io > does. The latter has little or no Javadoc. Yes we could assume that > gnu.io's documentation is identical to javax.comm but the fact remains > that code-completion won't bring up Javadoc for gnu.io. Gili, perhaps a highly motivated person, such as yourself, could fill in the Javadocs and contribute the patches back to RXTX? -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090416/79502619/attachment.html From cowwoc at bbs.darktech.org Thu Apr 16 14:47:27 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Thu, 16 Apr 2009 16:47:27 -0400 Subject: [Rxtx] Java5 support In-Reply-To: References: <91BF244D-07E4-4B30-9F9D-0DC0964045B4@cometway.com> <49E7900D.3060100@bbs.darktech.org> Message-ID: <49E7995F.1020304@bbs.darktech.org> Brian, I have already submitted two patches for RXTX in the past week alone... I understand that Sun's decision to drop Windows and Mac support angered quite a few people but I fail to see the link between the reference implementation (which angered you) and the specification (which by all accounts is great). Why not extend their specification and completely replace the implementation? From what I've read, javax.comm 3.0's API is completely backwards compatible to 2.0. On the flip side, if you're not interested in extending javax.comm, why not refactor the gnu.io package to improve usability and I would be more than happy to contribute a completely new Javadoc. Gili Brian Schlining wrote: > The fact that javax.comm has good Javadoc does not mean that > gnu.io > does. The latter has little or no Javadoc. Yes we could assume that > gnu.io 's documentation is identical to javax.comm > but the fact remains > that code-completion won't bring up Javadoc for gnu.io . > > > Gili, perhaps a highly motivated person, such as yourself, could fill in > the Javadocs and contribute the patches back to RXTX? > > -- > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > Brian Schlining > bschlining at gmail.com From talberts at msiscales.com Thu Apr 16 14:55:50 2009 From: talberts at msiscales.com (Tim Alberts) Date: Thu, 16 Apr 2009 13:55:50 -0700 Subject: [Rxtx] RXTX Simple Demo Program Message-ID: <49E79B56.5010604@msiscales.com> I don't think it exists yet, so I'd like to propose it be done. I would like to see a demo program that opens a serial port and allows transmitting/receiving of data and configuration of ports via the RXTX gnu.io software. One of the features that was driving me to move to RXTX (aside from Sun dropping support), was the upcoming ability to use web install. I have not kept up so I'm not sure yet if that is implemented, but if/when it is, a demo program to distribute via web install would be outstanding to see from RXTX. I know that Sun has (had) a blackbox demo program that tries to open every available serial port it finds on the computer and allows for transmit/receive and configuration of the serial port. This is pretty much what I have in mind for RXTX. Is this a reasonable request? -------------- next part -------------- A non-text attachment was scrubbed... Name: talberts.vcf Type: text/x-vcard Size: 337 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20090416/3986518c/attachment.vcf From tjarvi at qbang.org Thu Apr 16 14:56:35 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Apr 2009 14:56:35 -0600 (MDT) Subject: [Rxtx] Java5 support In-Reply-To: <49E7900D.3060100@bbs.darktech.org> References: <91BF244D-07E4-4B30-9F9D-0DC0964045B4@cometway.com> <49E7900D.3060100@bbs.darktech.org> Message-ID: On Thu, 16 Apr 2009, cowwoc wrote: > Paul Cunningham wrote: >> 2) There's nothing complicated about the javax.comm APIs and they are >> well Javadoc'ed all over the web. RXTX adherence to them has been very >> consistent. > > The fact that javax.comm has good Javadoc does not mean that gnu.io > does. The latter has little or no Javadoc. Yes we could assume that > gnu.io's documentation is identical to javax.comm but the fact remains > that code-completion won't bring up Javadoc for gnu.io. Secondly, > someone mentioned recently that although the APIs are supposed to be the > same, RXTX in fact behaves noticeably different from javax.comm. The > gnu.io specification needs to be nailed down one way or the other. > Hi Gili RXTX treats the javax.comm v2.0 API docs as the truth. When rxtx does not behave like the docs say, we treat it as a bug. If the bug really bothers someone, they fix it. That said, there will be behavior differences between the implementations. RXTX is not a 'bug per bug' implementation of javax.comm. Many default settings are not documented and can differ also. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Apr 16 15:47:24 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Apr 2009 15:47:24 -0600 (MDT) Subject: [Rxtx] Java5 support In-Reply-To: <49E7995F.1020304@bbs.darktech.org> References: <91BF244D-07E4-4B30-9F9D-0DC0964045B4@cometway.com> <49E7900D.3060100@bbs.darktech.org> <49E7995F.1020304@bbs.darktech.org> Message-ID: On Thu, 16 Apr 2009, cowwoc wrote: > On the flip side, if you're not interested in extending javax.comm, why > not refactor the gnu.io package to improve usability and I would be more > than happy to contribute a completely new Javadoc. Hi Gili, Changing the API to use the latest offerings in JREs is not in itself a good reason to break an API. If the functionality is there, this library is better off not changing because many applications count on that API remaining stable. If you have some usability issues that hold merit beyond your personal preferences and make sense to most of the people here, RXTX can change if it is obviously the right thing to do. -- Trent Jarvi tjarvi at qbang.org From paul at cometway.com Thu Apr 16 15:52:18 2009 From: paul at cometway.com (Paul Cunningham) Date: Thu, 16 Apr 2009 17:52:18 -0400 Subject: [Rxtx] Java5 support In-Reply-To: <49E7900D.3060100@bbs.darktech.org> References: <91BF244D-07E4-4B30-9F9D-0DC0964045B4@cometway.com> <49E7900D.3060100@bbs.darktech.org> Message-ID: <9146C76F-17D8-468D-A0F2-CAC9512BCDD6@cometway.com> Code completion... isn't that where you stub out some methods, check it into CVS, and the next day find out that someone else finished your work? ;-) Seemingly your project has exposed RXTX to more finicky devices than the ones I have worked with. I can understand why better Javadocs would be useful if you are using IDEs as a tool to learn and remember your APIs, and you sound qualified enough to contribute information about the kinds of idiosyncrasies between javax.comm and gui.io to the RXTX project. I also understand that you have read the javax.comm 3.0 APIs and are upset that no one has actually implemented them. An updated specification and your keen interest in seeing it implemented is apparently not enough to make that happen in a world where RS-232 is only used for legacy support of devices with no hope for firmware updates. -pc On Apr 16, 2009, at 4:07 PM, cowwoc wrote: > Paul Cunningham wrote: >> 2) There's nothing complicated about the javax.comm APIs and they >> are well Javadoc'ed all over the web. RXTX adherence to them has >> been very consistent. > > The fact that javax.comm has good Javadoc does not mean that gnu.io > does. The latter has little or no Javadoc. Yes we could assume that > gnu.io's documentation is identical to javax.comm but the fact > remains that code-completion won't bring up Javadoc for gnu.io. > Secondly, someone mentioned recently that although the APIs are > supposed to be the same, RXTX in fact behaves noticeably different > from javax.comm. The gnu.io specification needs to be nailed down > one way or the other. > > Gili > > From paul at cometway.com Thu Apr 16 16:14:16 2009 From: paul at cometway.com (Paul Cunningham) Date: Thu, 16 Apr 2009 18:14:16 -0400 Subject: [Rxtx] Java5 support In-Reply-To: <9146C76F-17D8-468D-A0F2-CAC9512BCDD6@cometway.com> References: <91BF244D-07E4-4B30-9F9D-0DC0964045B4@cometway.com> <49E7900D.3060100@bbs.darktech.org> <9146C76F-17D8-468D-A0F2-CAC9512BCDD6@cometway.com> Message-ID: <47F476E8-5F95-4521-A437-11622583210F@cometway.com> btw, i mean no disrespect to anyone actively developing an RS-232 interfaces for new devices. in fact my most recent project involved a freescale chip using a UART- to-USB chip, as i have no idea how to go about interfacing USB devices to Java. RXTX behaved very well, even when the USB driver didn't. is there anything resembling javax.comm for USB? -pc On Apr 16, 2009, at 5:52 PM, Paul Cunningham wrote: > in a world where RS-232 is > only used for legacy support of devices with no hope for firmware > updates. From tjarvi at qbang.org Thu Apr 16 16:50:12 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Apr 2009 16:50:12 -0600 (MDT) Subject: [Rxtx] Java5 support In-Reply-To: <47F476E8-5F95-4521-A437-11622583210F@cometway.com> References: <91BF244D-07E4-4B30-9F9D-0DC0964045B4@cometway.com> <49E7900D.3060100@bbs.darktech.org> <9146C76F-17D8-468D-A0F2-CAC9512BCDD6@cometway.com> <47F476E8-5F95-4521-A437-11622583210F@cometway.com> Message-ID: Hi Paul, JSR 80 is USB HID support. http://javax-usb.org/ http://jcp.org/aboutJava/communityprocess/final/jsr080/index.html On Thu, 16 Apr 2009, Paul Cunningham wrote: > btw, i mean no disrespect to anyone actively developing an RS-232 > interfaces for new devices. > > in fact my most recent project involved a freescale chip using a UART- > to-USB chip, as i have no idea how to go about interfacing USB devices > to Java. RXTX behaved very well, even when the USB driver didn't. > > is there anything resembling javax.comm for USB? -pc > > > On Apr 16, 2009, at 5:52 PM, Paul Cunningham wrote: > >> in a world where RS-232 is >> only used for legacy support of devices with no hope for firmware >> updates. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From cowwoc at bbs.darktech.org Thu Apr 16 16:57:43 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Thu, 16 Apr 2009 18:57:43 -0400 Subject: [Rxtx] Java5 support In-Reply-To: References: <91BF244D-07E4-4B30-9F9D-0DC0964045B4@cometway.com> <49E7900D.3060100@bbs.darktech.org> <9146C76F-17D8-468D-A0F2-CAC9512BCDD6@cometway.com> <47F476E8-5F95-4521-A437-11622583210F@cometway.com> Message-ID: <49E7B7E7.9050302@bbs.darktech.org> Last time I looked this, there was no usable Windows version. Gili Trent Jarvi wrote: > Hi Paul, > > JSR 80 is USB HID support. > > http://javax-usb.org/ > http://jcp.org/aboutJava/communityprocess/final/jsr080/index.html > > On Thu, 16 Apr 2009, Paul Cunningham wrote: > >> btw, i mean no disrespect to anyone actively developing an RS-232 >> interfaces for new devices. >> >> in fact my most recent project involved a freescale chip using a UART- >> to-USB chip, as i have no idea how to go about interfacing USB devices >> to Java. RXTX behaved very well, even when the USB driver didn't. >> >> is there anything resembling javax.comm for USB? -pc >> >> >> On Apr 16, 2009, at 5:52 PM, Paul Cunningham wrote: >> >>> in a world where RS-232 is >>> only used for legacy support of devices with no hope for firmware >>> updates. >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Apr 16 17:02:49 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Apr 2009 17:02:49 -0600 (MDT) Subject: [Rxtx] RXTX Simple Demo Program In-Reply-To: <49E79B56.5010604@msiscales.com> References: <49E79B56.5010604@msiscales.com> Message-ID: On Thu, 16 Apr 2009, Tim Alberts wrote: > I don't think it exists yet, so I'd like to propose it be done. I would like > to see a demo program that opens a serial port and allows > transmitting/receiving of data and configuration of ports via the RXTX gnu.io > software. > > One of the features that was driving me to move to RXTX (aside from Sun > dropping support), was the upcoming ability to use web install. I have not > kept up so I'm not sure yet if that is implemented, but if/when it is, a demo > program to distribute via web install would be outstanding to see from RXTX. > > I know that Sun has (had) a blackbox demo program that tries to open every > available serial port it finds on the computer and allows for > transmit/receive and configuration of the serial port. This is pretty much > what I have in mind for RXTX. > > Is this a reasonable request? > Hi Tim, It is a great request. I don't know if anyone will write tha application though. We could include it with rxtx as a demo like BlackBox was with Sun's commapi. But.. You can run Sun's BlackBox source code through the ChangePackage.sh and use BlackBox with rxtx 2.1/2.2 for personal use. ChangePackage.sh is in the contrib directory with the rxtx source code. As I recall, there was just one minor modification required - BlackBox had a hard coded number of ports which could cause problems. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Apr 16 20:25:29 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Apr 2009 20:25:29 -0600 (MDT) Subject: [Rxtx] Timeout patch In-Reply-To: <49E64A4A.1050806@bbs.darktech.org> References: <49E64A4A.1050806@bbs.darktech.org> Message-ID: On Wed, 15 Apr 2009, cowwoc wrote: > Hi, > > Please review the attached patch. > > - fixes disableReceiveTimeout() so reads now block until data is available. > - receive timeouts and threshold handling is now more consistent across all > implementations > Attached is the core change to serial Gili has suggested. I ran tests that cover about 40% of the serial code without regressions. If you happen to use the same 40%, you are safe :) Otherwise, I suggest trying the changes. I'd like to hear if this fixes issues for anyone. I put some binaries for win32, Mac and linux32 here: ftp://ftp.qbang.org/pub/rxtx/test-timeout.zip Unfortunately, The original patch tries to do several things. Some of the changes are not correct and require further review. This is just the timeout portion for serial code which I've reviewed and tested. -- Trent Jarvi tjarvi at qbang.org -------------- next part -------------- Index: src/SerialImp.c =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v retrieving revision 1.46.2.203 diff -u -r1.46.2.203 SerialImp.c --- src/SerialImp.c 19 Mar 2009 03:27:48 -0000 1.46.2.203 +++ src/SerialImp.c 17 Apr 2009 02:05:48 -0000 @@ -3298,6 +3298,8 @@ if (vtime < 0){ timeout = 0; + if (threshold <= 0) + threshold = 1; } else if (vtime == 0){ timeout = 1; Index: src/gnu/io/RXTXPort.java =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/gnu/io/RXTXPort.java,v retrieving revision 1.27.2.76 diff -u -r1.27.2.76 RXTXPort.java --- src/gnu/io/RXTXPort.java 13 Nov 2008 23:37:45 -0000 1.27.2.76 +++ src/gnu/io/RXTXPort.java 17 Apr 2009 02:05:48 -0000 @@ -1,7 +1,7 @@ /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. -| Copyright 1997-2008 by Trent Jarvi tjarvi at qbang.org and others who +| Copyright 1997-2009 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at @@ -398,19 +398,16 @@ { if (debug) z.reportln( "RXTXPort:enableReceiveTimeout() called"); - if( time >= 0 ) - { - timeout = time; - NativeEnableReceiveTimeoutThreshold( time , threshold, - InputBuffer ); - } - else + if( time < 0 ) { throw new IllegalArgumentException ( "Unexpected negative timeout value" ); } + timeout = time; + NativeEnableReceiveTimeoutThreshold( timeout , threshold, + InputBuffer ); if (debug) z.reportln( "RXTXPort:enableReceiveTimeout() returning"); } @@ -444,19 +441,16 @@ { if (debug) z.reportln( "RXTXPort:enableReceiveThreshold( " + thresh + " ) called"); - if(thresh >=0) - { - threshold=thresh; - NativeEnableReceiveTimeoutThreshold(timeout, threshold, - InputBuffer); - } - else /* invalid thresh */ + if(thresh < 1) { throw new IllegalArgumentException ( - "Unexpected negative threshold value" + "Threshold value must be possitive" ); } + threshold=thresh; + NativeEnableReceiveTimeoutThreshold(timeout, threshold, + InputBuffer); if (debug) z.reportln( "RXTXPort:enableReceiveThreshold( " + thresh + " ) returned"); } @@ -465,8 +459,12 @@ public void disableReceiveThreshold() { if (debug) - z.reportln( "RXTXPort:disableReceiveThreshold() called and returning"); - enableReceiveThreshold(0); + z.reportln( "RXTXPort:disableReceiveThreshold(0) called"); + threshold = 0; + NativeEnableReceiveTimeoutThreshold(timeout, threshold, + InputBuffer); + if (debug) + z.reportln( "RXTXPort:disableReceiveThreshold(0) returning"); } /** * @return int the recieve threshold @@ -1415,7 +1413,7 @@ */ int Minimum = len; - if( threshold==0 ) + if( threshold < 1 ) { /* * If threshold is disabled, read should return as soon @@ -1528,7 +1526,7 @@ */ int Minimum = len; - if( threshold==0 ) + if( threshold < 1 ) { /* * If threshold is disabled, read should return as soon From cowwoc at bbs.darktech.org Thu Apr 16 23:09:03 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Fri, 17 Apr 2009 01:09:03 -0400 Subject: [Rxtx] Problems with read timeout In-Reply-To: References: <49E64A4A.1050806@bbs.darktech.org> Message-ID: <49E80EEF.6000503@bbs.darktech.org> I've been playing with the read timeout behavior and I'm seeing some non-intuitive behavior. I've got an endless loop that does the following: 1) COM1 and COM2 are connected to one another. They are opened at 300 baud, with read timeout of 300ms. 2) COM1 writes "CONNECTION" 3) COM2 reads "CONNECTION" 4) COM2 writes "CONNECTION 9600 8 NONE 1 RTS/CTS" and tries a read operation. 5) COM1 receives "CONNECTION 960" when suddenly COM2 hits the 300ms read timeout. COM2 gets an IOException (caused by the timeout), and closes the serial port. 6) COM1 never gets the full message because the connection was closed in middle of sending. I want step 4 to block until COM1 receives the full message before it attempts the read operation but I'm not sure how to achieve this. I was somewhat expecting the write() or flush() operation to block until the send was complete... Any ideas? Gili From Steffen.DETTMER at ingenico.com Fri Apr 17 03:55:01 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 17 Apr 2009 11:55:01 +0200 Subject: [Rxtx] Java5 support In-Reply-To: <49E7900D.3060100@bbs.darktech.org> References: <91BF244D-07E4-4B30-9F9D-0DC0964045B4@cometway.com> <49E7900D.3060100@bbs.darktech.org> Message-ID: <20090417095501.GL13774@elberon.bln.de.ingenico.com> Hi, I cannot resist to make some comments, too :) In short, I think rxtx and gnu.io are good. Even if the API is `accidently' the same as javax.comm, logically rxtx IMHO is independent. It offers functionality an application can use - it does not need javax.comm at all. - IMHO Javadoc of javax.comm is /not/ good. What does it help to document `DATABITS_5' with `5 data bit format'? The documentation of SerialPort to me looks like what a less interested, less motivated student would write after failing a code review because of lack of documentation (review of course will fail again, even worse, because identifier <-> microdoc redundancy :)) There are so many issues with the docs... Also, those `optional functionality' is IMHO just a design bug. An interface is to define the interface, the features and functions that are available. Now Java has interfaces with optional functions. loooooooooool This ends that you have an application using this interface correctly and having a correct implementation of this interface but they do not work together because in fact they are using a different interface. It was hidden to the compiler by using `optional methods'. Just great. - namespace gnu.io IMHO is correct (well, don't know if gnu is correct etc, I just mean different from javax is) namespaces are exactly invented for such cases. Maybe gnu.io could implement javax.comm interfaces, maybe not. If someone really has a problem with package names, why not simply perl -npi -e 's/gnu.io/javax.comm/g' *.java could be some rule in some Makefile. - Some `wrapper' adding usability to the Java APIs (like InputStream) IMHO is essential and required anyway. I dislike the APIs, for instance InputStream and those. It is almost impossible to write really correct code with it. It is sufficient for simple GUI stuff you can kill if it blocks or so, but for e.g. server applications IMHO it is not sufficient. Timeouts are needed and so on. Well, this would just lead to a API discussion which would be a different topic. Because a wrapper is needed, package namings IMHO are no issue. Personally, I would prefer for some future version to drop the logical dependency to the stange javax.comm.SerialPort thingy, instead have a clean simple but specific JNI interface. This is `an implementation detail', so rxtx can do whatever is appropriate :) - this java event and multi-threading mixes IMHO often are just a workaround for a missing select(2). On linux, for instance, select and related functions are really strong. You can select in one and the same call a serial port, a TCP socket and a file if you want. In recently it seems Java people started to understand and did some new (not that new, java5 IIRC :)) APIs allowing things like that. They also introduced a new `ByteBuffer' for JNI performance IIRC. Applications using this also are not compatible to javax.comm. Also, the abstraction isn't sufficient IMHO, because applications cannot use InputStream because of missing timeouts, so they must use e.g. SerialPort and now all abstraction is gone, because timeouts for a SerialPort and SocketChannel are completely different in Java (unlike select(), which does abstract). So I think the `break' from javax.comm should be no issue. - rxtx is not required to provide high performance (I think). Of course it should be fast and stable, but IMHO no high performance is needed; typical applications probably just have to work with a few serial ports. When high performance is an issue, I think it would be required that on the JNI interface multiple ports can be processed with a single thread and a single call, for instance if data is buffered per port and the single call processes all active ports or so. In such a case I think it would be likely that a kind of BSD socket API interface would result as internal JNI interface, but this also is another topic. I think 64 port serial console servers are rare today and probably not implemented in Java :-) oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Steffen.DETTMER at ingenico.com Fri Apr 17 04:24:16 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 17 Apr 2009 12:24:16 +0200 Subject: [Rxtx] Problems with read timeout In-Reply-To: <49E80EEF.6000503@bbs.darktech.org> References: <49E64A4A.1050806@bbs.darktech.org> <49E80EEF.6000503@bbs.darktech.org> Message-ID: <20090417102416.GM13774@elberon.bln.de.ingenico.com> Hi, * cowwoc wrote on Fri, Apr 17, 2009 at 01:09 -0400: > I want step 4 to block until COM1 receives the full message before it Do you really want to block? Block means infinite timeout. In case of a serial communication issue (or such) your application will just hang. I think, usually, timeouts are no errors. On timeouts, often it is not correct to close the communication mean where it occured. > attempts the read operation but I'm not sure how to achieve > this. I was somewhat expecting the write() or flush() operation > to block until the send was complete... Any ideas? Typically you cannot know when the send really happend. OS buffers probably many bytes and UART several bits at least. With hardware flow control it might happen that sending a byte takes long time (seconds, minutes or even more). For testing your new implementation maybe you use some other tool (application or hardware, like a modem) to avoid that e.g. receive issues on one side are looking like send issues on the other - or so. Maybe you start some timer for a total timeout and call read in a loop (with the remaining time of the timer as timeout, half of the remaining time limited to a big fixed value or a small fixed value to poll)? When using small timeouts (lets say below 100 ms, not sure if 300 ms could be a problem too), be aware that because of interupt delays, other processes consuming CPU time or whatever reasons an operation can take longer, so a timer is expired but no timeout happend. Sometimes even (debug) log file writing can take so much or even more time. So for a more robust implementation it could help to invoke a read with a very short timeout right after the timer expired. If there is some (internally OS buffered) data it will be returned (this should not considered a timeout, i.e. not throw an exception). oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Kustaa.Nyholm at planmeca.com Fri Apr 17 05:54:50 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 17 Apr 2009 14:54:50 +0300 Subject: [Rxtx] Java5 support In-Reply-To: <9146C76F-17D8-468D-A0F2-CAC9512BCDD6@cometway.com> Message-ID: > From: Paul Cunningham > [snip] in a world where RS-232 is only used for legacy support of devices > with no hope for firmware updates. This is not entirely true. I mean there is a lot more to RS-232 than 'legacy support of devices with no hope for firmware updates'. The alternatives to RS-232 (USB comes to mind) are not that attractive to many niche device / system manufactures because implementing them and supporting them, especially across many platforms is often beyond their means and capabilities. Hence even new designs are based on RS232 on way or the other. RS232 is about the only easy(ish) way to access the outside world from in a relatively device and platform independent manor. Also even when implementing USB is feasible the other limitation of USB may make RS232 much more attractive proposition. Five meter cable length limitation and the utter unpracticality of implementing galvanic isolation come to mind. br Kusti BTW I did not quite get what the rest of the sentence ('with no hope for firmware updates') referred to. From Kustaa.Nyholm at planmeca.com Fri Apr 17 05:56:05 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 17 Apr 2009 14:56:05 +0300 Subject: [Rxtx] FW: Java5 support In-Reply-To: Message-ID: Ooops, sorry Gili, this was meant for the list. > From: Kustaa Nyholm > Date: Fri, 17 Apr 2009 14:41:48 +0300 > To: cowwoc > Conversation: [Rxtx] Java5 support > Subject: Re: [Rxtx] Java5 support > > > Nor Mac support and I think the Linux support is not complete either. > > It is a pity. I'm afraid it reflects the state of desktop Java which is sad > because there really are no alternative to Java for writing rich desktop > applications that look reasonably native on each of the three major platforms > in mostly platform agnostic way. > > br Kusti > >> From: cowwoc >> >> Last time I looked this, there was no usable Windows version. >> >> Gili >> >> Trent Jarvi wrote: >>> Hi Paul, >>> >>> JSR 80 is USB HID support. >>> >>> http://javax-usb.org/ >>> http://jcp.org/aboutJava/communityprocess/final/jsr080/index.html >>> >>> On Thu, 16 Apr 2009, Paul Cunningham wrote: >>> >>>> btw, i mean no disrespect to anyone actively developing an RS-232 >>>> interfaces for new devices. >>>> >>>> in fact my most recent project involved a freescale chip using a UART- >>>> to-USB chip, as i have no idea how to go about interfacing USB devices >>>> to Java. RXTX behaved very well, even when the USB driver didn't. >>>> >>>> is there anything resembling javax.comm for USB? -pc >>>> >>>> >>>> On Apr 16, 2009, at 5:52 PM, Paul Cunningham wrote: >>>> >>>>> in a world where RS-232 is >>>>> only used for legacy support of devices with no hope for firmware >>>>> updates. >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx ------ End of Forwarded Message From Kustaa.Nyholm at planmeca.com Fri Apr 17 05:56:42 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 17 Apr 2009 14:56:42 +0300 Subject: [Rxtx] FW: Java5 support In-Reply-To: Message-ID: Oops again, this was meant for the list. Sorry. ------ Forwarded Message > From: Kustaa Nyholm > Date: Fri, 17 Apr 2009 14:38:36 +0300 > To: Steffen DETTMER > Conversation: [Rxtx] Java5 support > Subject: Re: [Rxtx] Java5 support > >> From: Steffen DETTMER > >> - IMHO Javadoc of javax.comm is /not/ good....[SNIP] > Maybe documentation in javax.comm isnot first class but it is better than no > documentation. > > Having said that I have no desire to get this documentation copied over to > gnu.io I can just as well use the little bits I need from the javadocs of > javax.comm. > > After all this is a very small API and I would very much like it to stay that > way.e in some Makefile. >> >> - Some `wrapper' adding usability to the Java APIs (like >> InputStream) IMHO is essential and required anyway. >> > Me for one definitely don't need anywrapper, I'm happy with the way > the API is. javax.comm/gnu.io is a very low level abstraction of > the under laying hardware, and IMO it should stay that way. Anyone > interested in a better wrapper is of course free to implement and > publish one, if so inclined. But let's keep this in perspective, > serial port is small, but sometimes crucial, well established thing > that will not get better by braking things by improving it. > >> I dislike the APIs, for instance InputStream and those. It is >> almost impossible to write really correct code with it. It is >> sufficient for simple GUI stuff you can kill if it blocks or >> so, but for e.g. server applications IMHO it is not sufficient. >> Timeouts are needed and so on. > Would be fascinating to learn more about this as I've never had > any problem with APIs. > >> >> Well, this would just lead to a API discussion which would be a >> different topic. >> >> Because a wrapper is needed, package namings IMHO are no issue. >> Personally, I would prefer for some future version to drop the >> logical dependency to the stange javax.comm.SerialPort thingy, >> instead have a clean simple but specific JNI interface. >> This is `an implementation detail', so rxtx can do whatever is >> appropriate :) >> > I would suspect that most user would not welcome anything that brakes > compatibility with the existing API. Let's improve something in > a separate wrapper project. >> >> >> - this java event and multi-threading mixes IMHO often are just a >> workaround for a missing select(2). On linux, for instance, >> select and related functions are really strong. You can select >> in one and the same call a serial port, a TCP socket and a file >> if you want. In recently it seems Java people started to >> understand and did some new (not that new, java5 IIRC :)) APIs >> allowing things like that. They also introduced a new >> `ByteBuffer' for JNI performance IIRC. >> >> Applications using this also are not compatible to javax.comm. >> Also, the abstraction isn't sufficient IMHO, because >> applications cannot use InputStream because of missing >> timeouts, so they must use e.g. SerialPort and now all >> abstraction is gone, because timeouts for a SerialPort and >> SocketChannel are completely different in Java (unlike >> select(), which does abstract). > I'm not sure I followed/understood everything above but it smelt > like *one* POV and I suspect, that if I had understood what I read, that > I would have had a different POV. >> >> So I think the `break' from javax.comm should be no issue. > Depending on what above means this could be huge issues for many of us. > But I think I've said that several times already. >> >> >> >> - rxtx is not required to provide high performance (I think). > Agree. >> >> Of course it should be fast and stable, but IMHO no high >> performance is needed; typical applications probably just have >> to work with a few serial ports. > Agree. >> >> When high performance is an issue, I think it would be required >> that on the JNI interface multiple ports can be processed with >> a single thread and a single call, for instance if data is >> buffered per port and the single call processes all active >> ports or so. In such a case I think it would be likely that a >> kind of BSD socket API interface would result as internal JNI >> interface, but this also is another topic. > This paragraph had so many assumptions that I refrain from commenting > other than that it portrays one POV which again I suspect I do not > care for. >> >> I think 64 port serial console servers are rare today and >> probably not implemented in Java :-) >> >> >> oki, >> >> Steffen >> > br Kusti ------ End of Forwarded Message From Kustaa.Nyholm at planmeca.com Fri Apr 17 06:01:15 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 17 Apr 2009 15:01:15 +0300 Subject: [Rxtx] rxtx list configuration... Message-ID: Trent, Would it be possible to configure the mail headers for mail that comes from the list so that the 'from' field would be 'rxtx at qbang.org' and not the posters email address? That would save me a couple of clicks each time I reply (now I need to 'reply to all' and delete the other recipients) and a few mistakes (when I hit the 'reply to sender'). Just did that mistake twice in a row, my apologies for those concerned. Just a wish. br Kusti From ilkka at myller.com Fri Apr 17 06:17:14 2009 From: ilkka at myller.com (Ilkka Myller) Date: Fri, 17 Apr 2009 15:17:14 +0300 Subject: [Rxtx] Java5 support In-Reply-To: References: Message-ID: <934E311F-9FCC-4EF2-A1D5-960285363221@myller.com> I completely agree with Kustaa on this one. Our company is developing devices with embedded hardware. We are using RS-232 (and other serial interfaces) with both old and new designs. Serial interfaces are convenient/practical with embedded low cost microprocessors etc. where hardware/software overhead and complexity of more "modern" interfaces is just .. well.. overhead. So, in my opinion, RS-232 (and others) are not obsolete or legacy - at least in industrial/embedded development. It is true, that there are little or no new consumer devices with RS-232 interfaces. -- I >> From: Paul Cunningham >> [snip] in a world where RS-232 is only used for legacy support of >> devices >> with no hope for firmware updates. > > This is not entirely true. I mean there is a lot more to RS-232 than > 'legacy > support of devices with no hope for firmware updates'. > > The alternatives to RS-232 (USB comes to mind) are not that > attractive to > many niche device / system manufactures because implementing them and > supporting them, especially across many platforms is often beyond > their > means and capabilities. Hence even new designs are based on RS232 on > way > or the other. > > RS232 is about the only easy(ish) way to access the outside world > from in a > relatively device and platform independent manor. > > Also even when implementing USB is feasible the other limitation of > USB may > make RS232 much more attractive proposition. Five meter cable length > limitation and the utter unpracticality of implementing galvanic > isolation > come to mind. > > br Kusti > > BTW I did not quite get what the rest of the sentence ('with no hope > for > firmware updates') referred to. > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From cowwoc at bbs.darktech.org Fri Apr 17 06:48:31 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Fri, 17 Apr 2009 08:48:31 -0400 Subject: [Rxtx] Problems with read timeout In-Reply-To: <49E80EEF.6000503@bbs.darktech.org> References: <49E64A4A.1050806@bbs.darktech.org> <49E80EEF.6000503@bbs.darktech.org> Message-ID: <49E87A9F.9070200@bbs.darktech.org> To be clear, I'm not really sure I want write() to block. I just want a way to get a timeout if no data has been read or written in at least X ms (i.e. we're waiting on the remote end) *and* we're blocked on a read() or write() command. It's not clear to me how to achieve this, with or without the new NIO APIs. I'm fairly certain the only way this will work is if flush() blocks until the remote end receives the full message. I'll look into the C code later on tonight to see if this is possible. What are your thoughts on this? Gili cowwoc wrote: > > I've been playing with the read timeout behavior and I'm seeing some > non-intuitive behavior. > > I've got an endless loop that does the following: > > 1) COM1 and COM2 are connected to one another. They are opened at 300 > baud, with read timeout of 300ms. > 2) COM1 writes "CONNECTION" > 3) COM2 reads "CONNECTION" > 4) COM2 writes "CONNECTION 9600 8 NONE 1 RTS/CTS" and tries a read > operation. > 5) COM1 receives "CONNECTION 960" when suddenly COM2 hits the 300ms read > timeout. COM2 gets an IOException (caused by the timeout), and closes > the serial port. > 6) COM1 never gets the full message because the connection was closed in > middle of sending. > > I want step 4 to block until COM1 receives the full message before > it attempts the read operation but I'm not sure how to achieve this. I > was somewhat expecting the write() or flush() operation to block until > the send was complete... Any ideas? > > Gili > From cowwoc at bbs.darktech.org Wed Apr 1 22:05:13 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Thu, 02 Apr 2009 00:05:13 -0400 Subject: [Rxtx] Windows 64-bit support? Message-ID: <49D43979.4050702@bbs.darktech.org> Hi, I'd like to run RXTX under the Windows 64-bit JVM. Are there plans to release an official 64-bit version anytime soon? Gili From bill7007 at gmail.com Thu Apr 2 16:01:17 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Thu, 2 Apr 2009 18:01:17 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel Message-ID: Hi, I have an rxtx serial application that used to work reliably until I had to move it to newer hardware and kernel. Now, the application sometimes hangs near first port use. When it does hang, it can be released by starting a second copy of the application which is locked out of the ports but does release the first process. Upgraded from rxtx-2.1-7-r2 to rxtx-2.2pre2 but still hangs. Tried to rebuild on the target machine and ran into the 'UTS_RELEASE' undeclared problem so holding on that approach. Recompiled OK on a 2.6.9-42.0.3.ELsmp system. Debug messages were turned on using: "./configure --enable-DEBUG" and modified RXTXPort.java with: "debug = true;" "z = new Zystem(Zystem.PRINT_MODE);" Below is capture of the application with debugging enabled. It show the application hang point, and the second application's printout at the release point. (pre3 is the locally modified version of pre2) Any suggestions on how to pin this down further? Thanks, +BillJ $ java -version java version "1.5.0_06" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05) Java HotSpot(TM) Client VM (build 1.5.0_06-b05, mixed mode, sharing) $ uname -a Linux qms4 2.6.18-92.1.6.el5 #1 SMP Wed Jun 25 13:49:24 EDT 2008 i686 i686 i386 GNU/Linux ***CAPTURE: [qms at qms4 ~]$ ./qms/ScriptFiles/startup.sh Thu Apr 02 13:35:45 EDT 2009:Setting Log File to:/home/qms/qms/QMS.log Thu Apr 02 13:35:45 EDT 2009:TSettings.HandleIni:ReUsing Ini file:/home/qms/qms/qms.properties WARNING: RXTX Version mismatch Jar version = RXTX-2.2pre2 native lib Version = RXTX-2.2pre3 fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB2 fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB1 fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB0 fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile RXTXPort {} RXTX WARNING: This library was compiled to run with OS release 2.4.20 and you are currently running OS release 2.6.18-92.1.6.el5. In some cases this can be a problem. Try recompiling RXTX if you notice strange behavior. If you just compiled RXTX make sure /usr/include/linux is a symbolic link to the include files that came with the kernel source and not an older copy. press enter to continue RXTXPort:RXTXPort(/dev/ttyUSB2) called fhs_lock: creating lockfile: 10127 open: locking worked for /dev/ttyUSB2 open: fd returned is 8 RXTXPort:MontitorThread:MonitorThread() RXTXPort:MontitorThread:run() has_line_status_register_acess: Port does not support TIOCSERGETLSR init_threads: get eis init_threads: set eis init_threads: stop RXTXPort:RXTXPort(/dev/ttyUSB2) returns with fd = 8 RXTXPort:setSerialPortParams(38400 8 1 0) called RXTXPort:setSerialPortParams(38400 8 1 0) returning RXTXPort:getInputStream() called and returning Thu Apr 02 13:36:02 EDT 2009:TSerial[22]:Using Port:/dev/ttyUSB2 RXTXPort:getOutputStream() called and returning Thu Apr 02 13:36:02 EDT 2009:TSerial[22].Transmit:TN Entering RXTXPort:SerialOutputStream:write(4) writeArray() Leaving RXTXPort:SerialOutputStream:write(4) RXTXPort:SerialOutputStream:flush() enter RXTXPort:SerialOutputStream:flush() leave Thu Apr 02 13:36:02 EDT 2009:TSerial[22].Transmit:RV Entering RXTXPort:SerialOutputStream:write(4) writeArray() Leaving RXTXPort:SerialOutputStream:write(4) RXTXPort:SerialOutputStream:flush() enter RXTXPort:SerialInputStream:read(8192 0 8192) called ***FIRST PROCESS HANGS HERE ***THEN PROCEEDS AFTER SECOND PROCESS STARTS RXTXPort:SerialOutputStream:flush() leave Thu Apr 02 13:41:29 EDT 2009:TSerial[22].Transmit:IH9 Entering RXTXPort:SerialOutputStream:write(5) writeArray() Leaving RXTXPort:SerialOutputStream:write(5) RXTXPort:SerialOutputStream:flush() enter RXTXPort:SerialOutputStream:flush() leave Thu Apr 02 13:41:29 EDT 2009:TSerial[22].Transmit:IL11 ***END CAPTURE ***CAPTURE SECOND PROCESS FAILS OPEN [qms at qms4 ~]$ ./qms/ScriptFiles/startup.sh Thu Apr 02 13:41:27 EDT 2009:Setting Log File to:/home/qms/qms/QMS.log Thu Apr 02 13:41:27 EDT 2009:TSettings.HandleIni:ReUsing Ini file:/home/qms/qms/qms.properties WARNING: RXTX Version mismatch Jar version = RXTX-2.2pre2 native lib Version = RXTX-2.2pre3 fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB2: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB1: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB0: File exists fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB2: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB1: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB0: File exists fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile Thu Apr 02 13:41:30 EDT 2009:TIOBoard: java.io.IOException: java.io.IOException: TSerial[22]: Open Failed ***END CAPTURE -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090402/c66f8d70/attachment-0016.html From netbeans at gatworks.com Thu Apr 2 17:15:04 2009 From: netbeans at gatworks.com (U. George) Date: Thu, 02 Apr 2009 19:15:04 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: Message-ID: <49D546F8.20807@gatworks.com> > "z = new Zystem(Zystem.PRINT_MODE);" > Below is capture of the application with debugging enabled. It show > the application hang point, and the second application's printout at the > release point. (pre3 is the locally modified version of pre2) > Any suggestions on how to pin this down further? > Thanks, > +BillJ When perceived runability is hung, try a ^\ ( control \) on console. This gets the JVM to dump the stacks of all the java threads. If you know the thread that is stuck, then u can see what java statement its stuck at. From tjarvi at qbang.org Thu Apr 2 19:25:17 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 2 Apr 2009 19:25:17 -0600 (MDT) Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: <49D546F8.20807@gatworks.com> References: <49D546F8.20807@gatworks.com> Message-ID: On Thu, 2 Apr 2009, U. George wrote: >> "z = new Zystem(Zystem.PRINT_MODE);" >> Below is capture of the application with debugging enabled. It show >> the application hang point, and the second application's printout at the >> release point. (pre3 is the locally modified version of pre2) >> Any suggestions on how to pin this down further? >> Thanks, >> +BillJ > > When perceived runability is hung, try a ^\ ( control \) on console. > This gets the JVM to dump the stacks of all the java threads. > If you know the thread that is stuck, then u can see what java statement > its stuck at. I've also noticed some linux systems hanging with open/read/write and saw kacpid storms. I need to look at it more but did observe kacpid consuming a core and not returning to a normal state for a significant period of time. It was easy to observe from top sorted by CPU usage. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Apr 2 19:26:18 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 2 Apr 2009 19:26:18 -0600 (MDT) Subject: [Rxtx] Windows 64-bit support? In-Reply-To: <49D43979.4050702@bbs.darktech.org> References: <49D43979.4050702@bbs.darktech.org> Message-ID: On Thu, 2 Apr 2009, cowwoc wrote: > Hi, > > I'd like to run RXTX under the Windows 64-bit JVM. Are there plans > to release an official 64-bit version anytime soon? > It is in the prerelease and will be in the final release. I'm pushing it through as fast as I can in my free time. -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Thu Apr 2 22:57:34 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Fri, 03 Apr 2009 00:57:34 -0400 Subject: [Rxtx] Missing documentation In-Reply-To: References: <49D43979.4050702@bbs.darktech.org> Message-ID: <49D5973E.4050400@bbs.darktech.org> Hi, I noticed that RXTX 2.1 drops javax.comm support in favor of gnu.io. I have one major problem with this: the gui.io.* documentation is very poor. Many classes and methods have no Javadoc at all which makes them difficult to use. Please fix this for the final release. Thank you, Gili From alex.sas at freemail.hu Fri Apr 3 01:36:54 2009 From: alex.sas at freemail.hu (Sas Alex) Date: Fri, 3 Apr 2009 09:36:54 +0200 (CEST) Subject: [Rxtx] Serial port false reads Message-ID: Hi all, On Windows XP, using rxtx-2.1-7-r2 I have a program communicating on a serial line like the following (excerpt): { os.write(command); os.flush(); // Thread.sleep(period); // read response while(is.available() > 0) { is.read() } } If there is a sleep between the os.flush and the reading cycle the correct answer is received. Otherwise (sometimes) there are extra, erronous characters at the beginning of the answer, but the correct answer (according to the protocol) also arrives, afterwards. Is this a normal behaviour, one should wait before the read? If yes, is there a way to determine the minimum amount of time to wait for? Serial port params are: 9600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE. Thank you in advance, Alex ________________________________________________________ El?foglal?si akci? meghosszabb?tva! Korfui ?d?l?s m?r 56.910 Ft-t?l. http://www.budavartours.hu/gorogorszag/?utm_campaign=origo&utm_source=freemail_kimeno_090403&utm_medium=ct&utm_content=korfu_elofoglalasi_akcio#reg_Korfu -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090403/8f3650ea/attachment-0016.html From bill7007 at gmail.com Fri Apr 3 16:15:30 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Fri, 3 Apr 2009 18:15:30 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: <49D546F8.20807@gatworks.com> Message-ID: > When perceived runability is hung, try a ^\ ( control \) on console. >> This gets the JVM to dump the stacks of all the java threads. > > Good idea... A thread dump is below, it looks like only some system threads are in wait state which is probably normal. The "main" thread is stopped writing the first data out the serial port which should complete but its has stopped at: at gnu.io.RXTXPort.nativeDrain(Native Method) It show its state as runnable though. There is another thread, "SerialReader_22", that is waiting to read any data on the same port. I'll bring the app up under Netbeans debugger next. >> > I've also noticed some linux systems hanging with open/read/write and saw > kacpid storms. No CPU use going when it hangs, acts like a deadlock. THREAD DUMP AT HANG: Entering RXTXPort:SerialOutputStream:write(4) writeArray() Leaving RXTXPort:SerialOutputStream:write(4) RXTXPort:SerialOutputStream:flush() enter RXTXPort:SerialInputStream:read(8192 0 8192) called Full thread dump Java HotSpot(TM) Client VM (1.5.0_06-b05 mixed mode, sharing): "SerialReader_22" daemon prio=1 tid=0x087abf38 nid=0x3c8b runnable [0xb1a43000..0xb1a43f30] at gnu.io.RXTXPort.readArray(Native Method) at gnu.io.RXTXPort$SerialInputStream.read(RXTXPort.java:1454) - locked <0x88ca55b8> (a gnu.io.RXTXPort$SerialInputStream) at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:411) at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) - locked <0x88cab378> (a java.io.InputStreamReader) at java.io.InputStreamReader.read(InputStreamReader.java:167) at java.io.BufferedReader.fill(BufferedReader.java:136) at java.io.BufferedReader.readLine(BufferedReader.java:299) - locked <0x88cab378> (a java.io.InputStreamReader) at java.io.BufferedReader.readLine(BufferedReader.java:362) at qms.TSerialPort$SerialRead.run(TSerialPort.java:268) at java.lang.Thread.run(Thread.java:595) "Thread-1" prio=1 tid=0x08a43360 nid=0x3c8a runnable [0xb1ac4000..0xb1ac4db0] at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1641) "AWT-XAWT" daemon prio=1 tid=0x08acc848 nid=0x3c87 runnable [0xb1b45000..0xb1b45e30] at sun.awt.X11.XToolkit.waitForEvents(Native Method) at sun.awt.X11.XToolkit.run(XToolkit.java:463) at sun.awt.X11.XToolkit.run(XToolkit.java:438) at java.lang.Thread.run(Thread.java:595) "Java2D Disposer" daemon prio=1 tid=0x08ab9d30 nid=0x3c86 in Object.wait() [0xb1bc6000..0xb1bc70b0] at java.lang.Object.wait(Native Method) - waiting on <0x8917b110> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:116) - locked <0x8917b110> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:132) at sun.java2d.Disposer.run(Disposer.java:107) at java.lang.Thread.run(Thread.java:595) "Low Memory Detector" daemon prio=1 tid=0x087bea68 nid=0x3c84 runnable [0x00000000..0x00000000] "CompilerThread0" daemon prio=1 tid=0x087bd4c0 nid=0x3c83 waiting on condition [0x00000000..0xb23a7a18] "Signal Dispatcher" daemon prio=1 tid=0x087bc520 nid=0x3c82 runnable [0x00000000..0x00000000] "Finalizer" daemon prio=1 tid=0x087b5710 nid=0x3c81 in Object.wait() [0xb26a9000..0xb26a9f30] at java.lang.Object.wait(Native Method) - waiting on <0x8914a770> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:116) - locked <0x8914a770> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:132) at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159) "Reference Handler" daemon prio=1 tid=0x087b49c8 nid=0x3c80 in Object.wait() [0xb272a000..0xb272adb0] at java.lang.Object.wait(Native Method) - waiting on <0x8914a7f0> (a java.lang.ref.Reference$Lock) at java.lang.Object.wait(Object.java:474) at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116) - locked <0x8914a7f0> (a java.lang.ref.Reference$Lock) "main" prio=1 tid=0x08777b88 nid=0x3c7e runnable [0xbffa7000..0xbffa74f8] at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1248) at qms.TSerialPort.Transmit(TSerialPort.java:192) - locked <0x88c99a68> (a qms.TSerialPort) at qms.TIOBoard.GetIOBoardVersion(TIOBoard.java:168) at qms.TIOBoard.(TIOBoard.java:73) at qms.TQMS.(TQMS.java:47) at qms.MainForm.(MainForm.java:2076) at qms.MainForm.main(MainForm.java:2099) "VM Thread" prio=1 tid=0x087b1e20 nid=0x3c7f runnable "VM Periodic Task Thread" prio=1 tid=0x087bff50 nid=0x3c85 waiting on condition -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090403/20b7bca4/attachment-0015.html From Martin.Oberhuber at windriver.com Fri Apr 3 16:23:43 2009 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Sat, 4 Apr 2009 00:23:43 +0200 Subject: [Rxtx] Missing documentation In-Reply-To: <49D5973E.4050400@bbs.darktech.org> References: <49D43979.4050702@bbs.darktech.org> <49D5973E.4050400@bbs.darktech.org> Message-ID: <460801A4097E3D4CA04CC64EE648584809C8BD6F@ism-mail03.corp.ad.wrs.com> Hello Gili, The classes in the gnu.io namespace are designed to work exactly as their counterparts in the javax.comm namespace. Therefore, if you just take the javax.comm Javadocs that's what you want. Unfortunately I don't think we can just copy & paste the javax.comm Javadocs into RXTX due to license restrictions. I guess that's the main reason why RXTX is not (yet) Javadoc'd as extensively as it should be. Actually, writing Javadocs from scratch WITHOUT referencing the wording of the Sun Javadocs is not that easy. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of cowwoc > Sent: Freitag, 03. April 2009 06:58 > To: rxtx at qbang.org > Subject: [Rxtx] Missing documentation > > Hi, > > I noticed that RXTX 2.1 drops javax.comm support in favor > of gnu.io. > I have one major problem with this: the gui.io.* > documentation is very > poor. Many classes and methods have no Javadoc at all which > makes them > difficult to use. Please fix this for the final release. > > Thank you, > Gili > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Fri Apr 3 16:54:50 2009 From: netbeans at gatworks.com (U. George) Date: Fri, 03 Apr 2009 18:54:50 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: <49D546F8.20807@gatworks.com> Message-ID: <49D693BA.8060909@gatworks.com> I would have tried 2 or 3 "^\" . If things are stuck, then all will be at same 'java' instruction. If thread is moving, then one of the snapshots would be different. I *think* flushing/draining wont return until the kernel buffers to device have been accepted by device. Stuck/paused device? Bill Johnson wrote: > > > > > When perceived runability is hung, try a ^\ ( control \) on console. > This gets the JVM to dump the stacks of all the java threads. > > > Good idea... A thread dump is below, it looks like only some system > threads are in wait state which is prob From cowwoc at bbs.darktech.org Fri Apr 3 17:45:09 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Fri, 03 Apr 2009 19:45:09 -0400 Subject: [Rxtx] Missing documentation In-Reply-To: <460801A4097E3D4CA04CC64EE648584809C8BD6F@ism-mail03.corp.ad.wrs.com> References: <49D43979.4050702@bbs.darktech.org> <49D5973E.4050400@bbs.darktech.org> <460801A4097E3D4CA04CC64EE648584809C8BD6F@ism-mail03.corp.ad.wrs.com> Message-ID: <49D69F85.3030804@bbs.darktech.org> You could always send Sun a formal email and ask for permission to copy their Javadoc. I doubt they would give you problems. Gili Oberhuber, Martin wrote: > Hello Gili, > > The classes in the gnu.io namespace are designed to work exactly > as their counterparts in the javax.comm namespace. Therefore, > if you just take the javax.comm Javadocs that's what you want. > > Unfortunately I don't think we can just copy & paste the > javax.comm Javadocs into RXTX due to license restrictions. > > I guess that's the main reason why RXTX is not (yet) Javadoc'd > as extensively as it should be. Actually, writing Javadocs > from scratch WITHOUT referencing the wording of the Sun > Javadocs is not that easy. > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] >> On Behalf Of cowwoc >> Sent: Freitag, 03. April 2009 06:58 >> To: rxtx at qbang.org >> Subject: [Rxtx] Missing documentation >> >> Hi, >> >> I noticed that RXTX 2.1 drops javax.comm support in favor >> of gnu.io. >> I have one major problem with this: the gui.io.* >> documentation is very >> poor. Many classes and methods have no Javadoc at all which >> makes them >> difficult to use. Please fix this for the final release. >> >> Thank you, >> Gili >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> From cowwoc at bbs.darktech.org Sat Apr 4 15:13:38 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sat, 04 Apr 2009 17:13:38 -0400 Subject: [Rxtx] Java5 support Message-ID: <49D7CD82.1040904@bbs.darktech.org> Now that you dropped javax.comm support, how about improving the API by replacing Enumation by Iterator, int by enum, and using Generics? It would improve the usability of the API. Gili From cowwoc at bbs.darktech.org Sat Apr 4 16:12:13 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sat, 04 Apr 2009 18:12:13 -0400 Subject: [Rxtx] RXTX Version mismatch in 2.2pre2 Message-ID: <49D7DB3D.5040008@bbs.darktech.org> When using RXTX-2.2pre2 I always get the following message: WARNING: RXTX Version mismatch Jar version = RXTX-2.2pre1 native lib Version = RXTX-2.2pre2 I have double checked that I am using the correct Jar file. Is this a known bug in pre2? Gili From tjarvi at qbang.org Sat Apr 4 16:48:53 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Apr 2009 16:48:53 -0600 (MDT) Subject: [Rxtx] RXTX Version mismatch in 2.2pre2 In-Reply-To: <49D7DB3D.5040008@bbs.darktech.org> References: <49D7DB3D.5040008@bbs.darktech.org> Message-ID: > When using RXTX-2.2pre2 I always get the following message: > > WARNING: RXTX Version mismatch > Jar version = RXTX-2.2pre1 > native lib Version = RXTX-2.2pre2 > Yep. You should still be able to test it. -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Sat Apr 4 16:50:43 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sat, 04 Apr 2009 18:50:43 -0400 Subject: [Rxtx] RXTX Version mismatch in 2.2pre2 In-Reply-To: References: <49D7DB3D.5040008@bbs.darktech.org> Message-ID: <49D7E443.9070404@bbs.darktech.org> In other words this is a known bug that will be fixed in the final version? Gili Trent Jarvi wrote: > > >> When using RXTX-2.2pre2 I always get the following message: >> >> WARNING: RXTX Version mismatch >> Jar version = RXTX-2.2pre1 >> native lib Version = RXTX-2.2pre2 >> > > Yep. > > You should still be able to test it. > > -- > Trent Jarvi > tjarvi at qbang.org From cowwoc at bbs.darktech.org Sat Apr 4 16:57:34 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sat, 04 Apr 2009 18:57:34 -0400 Subject: [Rxtx] IOException: Underlying input stream returned zero bytes Message-ID: <49D7E5DE.2050405@bbs.darktech.org> Hi, There seems to be a bug in RXTX 2.2pre2's handling of InputStream timeouts. If you open a serial port without ever invoking enableReceiveTimeout() then invoking InputStream.read() will always return 0 bytes right away. If you wrap the InputStream and invoke BufferedReader.readline() you will get the following exception: java.io.IOException: Underlying input stream returned zero bytes at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:268) [na:1.6.0_14-ea] at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:306) [na:1.6.0_14-ea] at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:158) [na:1.6.0_14-ea] at java.io.InputStreamReader.read(InputStreamReader.java:167) [na:1.6.0_14-ea] at java.io.BufferedReader.fill(BufferedReader.java:136) [na:1.6.0_14-ea] at java.io.BufferedReader.readLine(BufferedReader.java:299) [na:1.6.0_14-ea] at java.io.BufferedReader.readLine(BufferedReader.java:362) [na:1.6.0_14-ea] [snip] If you enable a timeout, the exception will only occur after the timeout expires. In short, it looks like RXTX is using a default timeout of zero (I am expecting it to block forever). It looks like other people have run into this as well: http://forums.sun.com/thread.jspa?threadID=5165346&start=10&tstart=0 Please confirm whether this is a known bug. Thank you, Gili From tjarvi at qbang.org Sat Apr 4 17:27:19 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Apr 2009 17:27:19 -0600 (MDT) Subject: [Rxtx] IOException: Underlying input stream returned zero bytes In-Reply-To: <49D7E5DE.2050405@bbs.darktech.org> References: <49D7E5DE.2050405@bbs.darktech.org> Message-ID: On Sat, 4 Apr 2009, cowwoc wrote: > Hi, > > There seems to be a bug in RXTX 2.2pre2's handling of InputStream > timeouts. If you open a serial port without ever invoking > enableReceiveTimeout() then invoking InputStream.read() will always > return 0 bytes right away. If you wrap the InputStream and invoke > BufferedReader.readline() you will get the following exception: > > java.io.IOException: Underlying input stream returned zero bytes > at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:268) > [na:1.6.0_14-ea] > at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:306) > [na:1.6.0_14-ea] > at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:158) > [na:1.6.0_14-ea] > at java.io.InputStreamReader.read(InputStreamReader.java:167) > [na:1.6.0_14-ea] > at java.io.BufferedReader.fill(BufferedReader.java:136) > [na:1.6.0_14-ea] > at java.io.BufferedReader.readLine(BufferedReader.java:299) > [na:1.6.0_14-ea] > at java.io.BufferedReader.readLine(BufferedReader.java:362) > [na:1.6.0_14-ea] > [snip] > > If you enable a timeout, the exception will only occur after the > timeout expires. In short, it looks like RXTX is using a default timeout > of zero (I am expecting it to block forever). It looks like other people > have run into this as well: > http://forums.sun.com/thread.jspa?threadID=5165346&start=10&tstart=0 > > Please confirm whether this is a known bug. > Hi Gili I've known about it but was not sure if it was a bug or not. It looks like we can treat it as a bug if nio is throwing an exception. Timeout and Thresholds are well documented in javax.comm but I didn't recall seeing defaults. For that reason, I've encouraged people to set the threshold and timeout to what they expect. Another note about InputStream.read(void): I noticed that I don't use that function at all while looking at code coverage results. Keep your eye out for additional issues. -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Sat Apr 4 19:03:29 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sat, 04 Apr 2009 21:03:29 -0400 Subject: [Rxtx] IOException: Underlying input stream returned zero bytes In-Reply-To: References: <49D7E5DE.2050405@bbs.darktech.org> Message-ID: <49D80361.7020801@bbs.darktech.org> Trent Jarvi wrote: > For that reason, I've encouraged people to set the threshold and timeout > to what they expect. It doesn't help. There doesn't seem to be a way to disable the timeout, even if you invoke disableReceiveTimeout() explicitly. Let me know when you put in a fix and I will test it. Thanks, Gili From cowwoc at bbs.darktech.org Sat Apr 4 23:27:25 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 01:27:25 -0400 Subject: [Rxtx] Crash in termios.c:892 Message-ID: <49D8413D.7040105@bbs.darktech.org> I can reproduce a crash in RXTX 2.2 pre2 100% of the time using my application code, but I can't seem to bring it down to a minimal testcase. Here is what I see: - thread begins running - open com1 - close com1 - open com5 - leave com5 open - thread shuts down - repeat the same process in a new thread - crash occurs when trying to open com1. Crash disappears if I close() com5 in the previous thread. The output window contains the following: # # A fatal error has been detected by the Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x05475cf6, pid=6064, tid=5436 # # JRE version: 6.0_14-b04 # Java VM: Java HotSpot(TM) Client VM (14.0-b13 mixed mode, sharing windows-x86 ) # Problematic frame: # C [rxtxSerial.dll+0x5cf6] # # An error report file with more information is saved as: # C:\Users\Gili\Documents\foobar\source\hs_err_pid6064.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp Error 0x5 at ..\src\termios.c(892): Access is denied. # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # Please let me know if the crash dump is enough to track down this bug. Thank you, Gili -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: hs_err_pid6064.log Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20090405/7133a1ce/attachment-0012.pl From cowwoc at bbs.darktech.org Sun Apr 5 00:24:19 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 02:24:19 -0400 Subject: [Rxtx] SerialPort.getName() is wrong Message-ID: <49D84E93.7050606@bbs.darktech.org> Sorry for all these emails but I keep on running into more issues. Here is what I noticed: - CommPortIdentifier.getPortIdentifier("COM5") returns a CommPortIdentifier where getName() == "COM5" - If, however, you invoke CommPortIdentifier.open() you get back a SerialPort where SerialPort.getName() is "//./COM5" I am expecting the name to remain consistent. "//./COM5" looks like an implementation detail and (as far as I can tell) it can't be used as an argument for any API method so it is somewhat useless. If getName() were to return "COM5" I could at least use it to get back the original CommPortIdentifier or compare against "known names" such as "COMx" or "LPTx". What do you think? Gili From tjarvi at qbang.org Sun Apr 5 10:18:42 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Apr 2009 10:18:42 -0600 (MDT) Subject: [Rxtx] SerialPort.getName() is wrong In-Reply-To: <49D84E93.7050606@bbs.darktech.org> References: <49D84E93.7050606@bbs.darktech.org> Message-ID: On Sun, 5 Apr 2009, cowwoc wrote: > > Sorry for all these emails but I keep on running into more issues. > Here is what I noticed: > > - CommPortIdentifier.getPortIdentifier("COM5") returns a > CommPortIdentifier where getName() == "COM5" > - If, however, you invoke CommPortIdentifier.open() you get back a > SerialPort where SerialPort.getName() is "//./COM5" > > I am expecting the name to remain consistent. "//./COM5" looks like > an implementation detail and (as far as I can tell) it can't be used as > an argument for any API method so it is somewhat useless. If getName() > were to return "COM5" I could at least use it to get back the original > CommPortIdentifier or compare against "known names" such as "COMx" or > "LPTx". What do you think? > Sure. If it itches enough you should be able to fix this in RXTXCommDriver.java. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Apr 5 10:27:58 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Apr 2009 10:27:58 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D8413D.7040105@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> Message-ID: On Sun, 5 Apr 2009, cowwoc wrote: > > I can reproduce a crash in RXTX 2.2 pre2 100% of the time using my > application code, but I can't seem to bring it down to a minimal testcase. > Here is what I see: > > - thread begins running > - open com1 > - close com1 > - open com5 > - leave com5 open > - thread shuts down > - repeat the same process in a new thread > - crash occurs when trying to open com1. Crash disappears if I close() com5 > in the previous thread. > > The output window contains the following: > > # > # A fatal error has been detected by the Java Runtime Environment: > # > # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x05475cf6, pid=6064, > tid=5436 > # > # JRE version: 6.0_14-b04 > # Java VM: Java HotSpot(TM) Client VM (14.0-b13 mixed mode, sharing > windows-x86 ) > # Problematic frame: > # C [rxtxSerial.dll+0x5cf6] > # > # An error report file with more information is saved as: > # C:\Users\Gili\Documents\foobar\source\hs_err_pid6064.log > # > # If you would like to submit a bug report, please visit: > # http://java.sun.com/webapps/bugreport/crash.jsp > Error 0x5 at ..\src\termios.c(892): Access is denied. > > > # The crash happened outside the Java Virtual Machine in native code. > # See problematic frame for where to report the bug. > # > > Please let me know if the crash dump is enough to track down this bug. > Hi Gili, You are responsible for cleaning up the serial ports when using threads. That said, if the thread did shut down, finalize should have been called if you are not passing the object around. See RXTXPort.java. protected void finalize() { if (debug) z.reportln( "RXTXPort:finalize()"); if( fd > 0 ) { if (debug) z.reportln( "RXTXPort:calling close()"); close(); } z.finalize(); } The exception is interesting. This is on Vista? Usually it just gives an open error when another process has the port. -- Trent Jarvi tjarvi at mathworks.com From cowwoc at bbs.darktech.org Sun Apr 5 10:35:55 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 12:35:55 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: References: <49D8413D.7040105@bbs.darktech.org> Message-ID: <49D8DDEB.5010908@bbs.darktech.org> Trent Jarvi wrote: > You are responsible for cleaning up the serial ports when using threads. > That said, if the thread did shut down, finalize should have been called > if you are not passing the object around. See RXTXPort.java. > > protected void finalize() > { > if (debug) > z.reportln( "RXTXPort:finalize()"); > if( fd > 0 ) > { > if (debug) > z.reportln( "RXTXPort:calling close()"); > close(); > } > z.finalize(); > } Two points: 1) One should never rely on finalizers because they may never run. 2) RXTX shouldn't cause the entire JVM to crash if I misuse the API. The native code should recover more gracefully. > The exception is interesting. This is on Vista? Usually it just gives > an open error when another process has the port. Yes, this is on Vista 64-bit. I'd really like to see this bug fixed. Is this code compilable under Visual Studio? If so, I can debug the problem on my end and send you a patch. Thanks, Gili From cowwoc at bbs.darktech.org Sun Apr 5 10:36:20 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 12:36:20 -0400 Subject: [Rxtx] SerialPort.getName() is wrong In-Reply-To: References: <49D84E93.7050606@bbs.darktech.org> Message-ID: <49D8DE04.6030306@bbs.darktech.org> Trent Jarvi wrote: >> I am expecting the name to remain consistent. "//./COM5" looks like >> an implementation detail and (as far as I can tell) it can't be used as >> an argument for any API method so it is somewhat useless. If getName() >> were to return "COM5" I could at least use it to get back the original >> CommPortIdentifier or compare against "known names" such as "COMx" or >> "LPTx". What do you think? >> > > Sure. > > If it itches enough you should be able to fix this in RXTXCommDriver.java. I'm not sure I understand. Are you saying that if I submit a patch you will commit it? Gili From tjarvi at qbang.org Sun Apr 5 10:46:23 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Apr 2009 10:46:23 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D8DDEB.5010908@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> Message-ID: On Sun, 5 Apr 2009, cowwoc wrote: > Trent Jarvi wrote: >> You are responsible for cleaning up the serial ports when using threads. >> That said, if the thread did shut down, finalize should have been called if >> you are not passing the object around. See RXTXPort.java. >> >> protected void finalize() >> { >> if (debug) >> z.reportln( "RXTXPort:finalize()"); >> if( fd > 0 ) >> { >> if (debug) >> z.reportln( "RXTXPort:calling close()"); >> close(); >> } >> z.finalize(); >> } > > Two points: > > 1) One should never rely on finalizers because they may never run. > 2) RXTX shouldn't cause the entire JVM to crash if I misuse the API. The > native code should recover more gracefully. > >> The exception is interesting. This is on Vista? Usually it just gives an >> open error when another process has the port. > > Yes, this is on Vista 64-bit. I'd really like to see this bug fixed. > Is this code compilable under Visual Studio? If so, I can debug the problem > on my end and send you a patch. > It will compile with the msvc cl.exe and nmake. See Makefile.msvc in the top level directory. You will need to adjust the JAVA_HOME variable. Also use the MSVC command prompt for x86_64 so cl and nmake are on your path. All the best, -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Apr 5 10:49:10 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Apr 2009 10:49:10 -0600 (MDT) Subject: [Rxtx] SerialPort.getName() is wrong In-Reply-To: <49D8DE04.6030306@bbs.darktech.org> References: <49D84E93.7050606@bbs.darktech.org> <49D8DE04.6030306@bbs.darktech.org> Message-ID: On Sun, 5 Apr 2009, cowwoc wrote: > Trent Jarvi wrote: >>> I am expecting the name to remain consistent. "//./COM5" looks like >>> an implementation detail and (as far as I can tell) it can't be used as >>> an argument for any API method so it is somewhat useless. If getName() >>> were to return "COM5" I could at least use it to get back the original >>> CommPortIdentifier or compare against "known names" such as "COMx" or >>> "LPTx". What do you think? >>> >> >> Sure. >> >> If it itches enough you should be able to fix this in RXTXCommDriver.java. > > I'm not sure I understand. Are you saying that if I submit a patch > you will commit it? > Hi Gili, Post a patch here and if nobody complains, we will commit it and give you credit. Yep. Other issues like changing the API to use java5 that may break existing apps are likely to run into objections but bug fixes usually get fixed just as you mention. -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Sun Apr 5 10:55:07 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 12:55:07 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> Message-ID: <49D8E26B.2040705@bbs.darktech.org> Trent Jarvi wrote: > It will compile with the msvc cl.exe and nmake. See Makefile.msvc in > the top level directory. You will need to adjust the JAVA_HOME > variable. Also use the MSVC command prompt for x86_64 so cl and nmake > are on your path. This is very odd. The CVS version of the code does not contain this file. Do you keep the latest code somewhere else? Gili From cowwoc at bbs.darktech.org Sun Apr 5 11:01:58 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 13:01:58 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D8E26B.2040705@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> Message-ID: <49D8E406.10708@bbs.darktech.org> cowwoc wrote: > Trent Jarvi wrote: >> It will compile with the msvc cl.exe and nmake. See Makefile.msvc in >> the top level directory. You will need to adjust the JAVA_HOME >> variable. Also use the MSVC command prompt for x86_64 so cl and nmake >> are on your path. > > This is very odd. The CVS version of the code does not contain this > file. Do you keep the latest code somewhere else? Okay I figured it out. CVS head is out of date, the "commapi-0-0-1" revision contains the correct files. Gili From tjarvi at qbang.org Sun Apr 5 11:05:43 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Apr 2009 11:05:43 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D8E26B.2040705@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> Message-ID: CVS HEAD is currently the rxtx 2.0 code. A branch was created long ago for 'experimental' gnu.io work. It just happens that the branch is what everyone uses now. checkout -r commapi-0-0-1 rxtx-devel will get the branch On Sun, 5 Apr 2009, cowwoc wrote: > Trent Jarvi wrote: >> It will compile with the msvc cl.exe and nmake. See Makefile.msvc in the >> top level directory. You will need to adjust the JAVA_HOME variable. Also >> use the MSVC command prompt for x86_64 so cl and nmake are on your path. > > This is very odd. The CVS version of the code does not contain this > file. Do you keep the latest code somewhere else? > > Gili > From cowwoc at bbs.darktech.org Sun Apr 5 14:50:47 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 16:50:47 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> Message-ID: <49D919A7.1070806@bbs.darktech.org> Okay, I tracked down the crash. It's being caused by YACK() using a 80-character buffer. The error message is longer than 80 characters, so _snprintf_s() crashes to avoid a buffer overflow. Please apply the attached patch and add the zipped up Visual Studio project directory. It's not perfect yet but it's a good start. Gili Trent Jarvi wrote: > > CVS HEAD is currently the rxtx 2.0 code. A branch was created long > ago for 'experimental' gnu.io work. It just happens that the branch > is what everyone uses now. > > checkout -r commapi-0-0-1 rxtx-devel > > will get the branch > > On Sun, 5 Apr 2009, cowwoc wrote: > >> Trent Jarvi wrote: >>> It will compile with the msvc cl.exe and nmake. See Makefile.msvc >>> in the top level directory. You will need to adjust the JAVA_HOME >>> variable. Also use the MSVC command prompt for x86_64 so cl and >>> nmake are on your path. >> >> This is very odd. The CVS version of the code does not contain >> this file. Do you keep the latest code somewhere else? >> >> Gili >> -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx-devel.patch Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20090405/d9b82962/attachment-0011.pl -------------- next part -------------- A non-text attachment was scrubbed... Name: Win32.zip Type: application/octet-stream Size: 17764 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20090405/d9b82962/attachment-0013.obj From cowwoc at bbs.darktech.org Sun Apr 5 15:22:01 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 17:22:01 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D919A7.1070806@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> <49D919A7.1070806@bbs.darktech.org> Message-ID: <49D920F9.6080702@bbs.darktech.org> My mistake. The problem in YACK is real, but it isn't the real cause of the crash. The crash is caused by termios.c line 1099: index->prev->next = port; because in my case "index->prev==0". I think the bug is that the code assumes that index will contain a minimum of two entries if we're inserting a previously closed fd. In my case, it only contains one. I'm not sure why you have this code branch (as opposed to appending to the end of index). Please take a look. Thanks, Gili cowwoc wrote: > > Okay, I tracked down the crash. It's being caused by YACK() using a > 80-character buffer. The error message is longer than 80 characters, so > _snprintf_s() crashes to avoid a buffer overflow. > > Please apply the attached patch and add the zipped up Visual Studio > project directory. It's not perfect yet but it's a good start. > > Gili > > Trent Jarvi wrote: >> >> CVS HEAD is currently the rxtx 2.0 code. A branch was created long >> ago for 'experimental' gnu.io work. It just happens that the branch >> is what everyone uses now. >> >> checkout -r commapi-0-0-1 rxtx-devel >> >> will get the branch >> >> On Sun, 5 Apr 2009, cowwoc wrote: >> >>> Trent Jarvi wrote: >>>> It will compile with the msvc cl.exe and nmake. See Makefile.msvc >>>> in the top level directory. You will need to adjust the JAVA_HOME >>>> variable. Also use the MSVC command prompt for x86_64 so cl and >>>> nmake are on your path. >>> >>> This is very odd. The CVS version of the code does not contain >>> this file. Do you keep the latest code somewhere else? >>> >>> Gili >>> From tjarvi at qbang.org Sun Apr 5 16:13:27 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Apr 2009 16:13:27 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D920F9.6080702@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> <49D919A7.1070806@bbs.darktech.org> <49D920F9.6080702@bbs.darktech.org> Message-ID: Hi Gili, Are you using the cvs version? I thought we fixed the linked list issues. A solution was posted to the list. Let me look at work tomorrow to see what I have. On Sun, 5 Apr 2009, cowwoc wrote: > > My mistake. The problem in YACK is real, but it isn't the real cause > of the crash. The crash is caused by termios.c line 1099: > > index->prev->next = port; > > because in my case "index->prev==0". I think the bug is that the code > assumes that index will contain a minimum of two entries if we're inserting a > previously closed fd. In my case, it only contains one. > > I'm not sure why you have this code branch (as opposed to appending > to the end of index). Please take a look. > > Thanks, > Gili > > cowwoc wrote: >> >> Okay, I tracked down the crash. It's being caused by YACK() using a >> 80-character buffer. The error message is longer than 80 characters, so >> _snprintf_s() crashes to avoid a buffer overflow. >> >> Please apply the attached patch and add the zipped up Visual Studio >> project directory. It's not perfect yet but it's a good start. >> >> Gili >> >> Trent Jarvi wrote: >>> >>> CVS HEAD is currently the rxtx 2.0 code. A branch was created long ago >>> for 'experimental' gnu.io work. It just happens that the branch is what >>> everyone uses now. >>> >>> checkout -r commapi-0-0-1 rxtx-devel >>> >>> will get the branch >>> >>> On Sun, 5 Apr 2009, cowwoc wrote: >>> >>>> Trent Jarvi wrote: >>>>> It will compile with the msvc cl.exe and nmake. See Makefile.msvc in >>>>> the top level directory. You will need to adjust the JAVA_HOME >>>>> variable. Also use the MSVC command prompt for x86_64 so cl and nmake >>>>> are on your path. >>>> >>>> This is very odd. The CVS version of the code does not contain this >>>> file. Do you keep the latest code somewhere else? >>>> >>>> Gili >>>> > From ilkka at myller.com Sun Apr 5 23:58:08 2009 From: ilkka at myller.com (Ilkka Myller) Date: Mon, 6 Apr 2009 08:58:08 +0300 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> <49D919A7.1070806@bbs.darktech.org> <49D920F9.6080702@bbs.darktech.org> Message-ID: <19779C97-E0C7-4E3D-B715-F84F50F00CE6@myller.com> Hi all, I've already submitted the patch to fix this issue in february: http://mailman.qbang.org/pipermail/rxtx/2009-February/3989441.html The patch fixes the mentioned doubly linked list handling in termios.c -- I Trent Jarvi kirjoitti 6.4.2009 kello 1.13: > > Hi Gili, > > Are you using the cvs version? I thought we fixed the linked list > issues. > A solution was posted to the list. Let me look at work tomorrow to > see > what I have. > > > > On Sun, 5 Apr 2009, cowwoc wrote: > >> >> My mistake. The problem in YACK is real, but it isn't the real cause >> of the crash. The crash is caused by termios.c line 1099: >> >> index->prev->next = port; >> >> because in my case "index->prev==0". I think the bug is that the >> code >> assumes that index will contain a minimum of two entries if we're >> inserting a >> previously closed fd. In my case, it only contains one. >> >> I'm not sure why you have this code branch (as opposed to appending >> to the end of index). Please take a look. >> >> Thanks, >> Gili >> >> cowwoc wrote: >>> >>> Okay, I tracked down the crash. It's being caused by YACK() >>> using a >>> 80-character buffer. The error message is longer than 80 >>> characters, so >>> _snprintf_s() crashes to avoid a buffer overflow. >>> >>> Please apply the attached patch and add the zipped up Visual >>> Studio >>> project directory. It's not perfect yet but it's a good start. >>> >>> Gili >>> >>> Trent Jarvi wrote: >>>> >>>> CVS HEAD is currently the rxtx 2.0 code. A branch was created >>>> long ago >>>> for 'experimental' gnu.io work. It just happens that the branch >>>> is what >>>> everyone uses now. >>>> >>>> checkout -r commapi-0-0-1 rxtx-devel >>>> >>>> will get the branch >>>> >>>> On Sun, 5 Apr 2009, cowwoc wrote: >>>> >>>>> Trent Jarvi wrote: >>>>>> It will compile with the msvc cl.exe and nmake. See >>>>>> Makefile.msvc in >>>>>> the top level directory. You will need to adjust the JAVA_HOME >>>>>> variable. Also use the MSVC command prompt for x86_64 so cl and >>>>>> nmake >>>>>> are on your path. >>>>> >>>>> This is very odd. The CVS version of the code does not >>>>> contain this >>>>> file. Do you keep the latest code somewhere else? >>>>> >>>>> Gili >>>>> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Steffen.DETTMER at ingenico.com Mon Apr 6 02:53:47 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 6 Apr 2009 10:53:47 +0200 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D919A7.1070806@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> <49D919A7.1070806@bbs.darktech.org> Message-ID: <20090406085347.GM8289@elberon.bln.de.ingenico.com> Hi, just two minor details, first about the errno change, I though #include extern int errno; is correct (POSIX.1) - why this change? second about the log message, I think the maximum length could be limited and the return value of malloc must be checked for != NULL before using. Should it be _snprintf_s( message, 80, _TRUNCATE, "Error 0x%x at %s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); (I know that MS-CRT _snprintf does not guarantee to have a final EOS, but I think _snprintf_s with _TRUNCATE does so?). If it is known that truncation may happen maybe sizeof[message] could be increased; maybe using some %.20s could be used avoiding __FILE__ including big pathes to a message where all the message had been cut-off. To have it portable I think it could be: /* generally: */ #if defined(_MSC_VER) # define snprintf _snprintf #endif snprintf(message, sizeof(message), "Error 0x%x at %.20s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); message[sizeof(message)-1] = '\0'; /* needed for MS CRT snprintf */ (for length and size parameter I think size_t could be an option, but on several platforms, including MS-CRT and older glibc, there is no %z, unfortunately) oki, Steffen * cowwoc wrote on Sun, Apr 05, 2009 at 16:50 -0400: > > Okay, I tracked down the crash. It's being caused by YACK() using a > 80-character buffer. The error message is longer than 80 characters, so > _snprintf_s() crashes to avoid a buffer overflow. > > Please apply the attached patch and add the zipped up Visual Studio > project directory. It's not perfect yet but it's a good start. > > Gili > > Trent Jarvi wrote: > > > >CVS HEAD is currently the rxtx 2.0 code. A branch was created long > >ago for 'experimental' gnu.io work. It just happens that the branch > >is what everyone uses now. > > > >checkout -r commapi-0-0-1 rxtx-devel > > > >will get the branch > > > >On Sun, 5 Apr 2009, cowwoc wrote: > > > >>Trent Jarvi wrote: > >>>It will compile with the msvc cl.exe and nmake. See Makefile.msvc > >>>in the top level directory. You will need to adjust the JAVA_HOME > >>>variable. Also use the MSVC command prompt for x86_64 so cl and > >>>nmake are on your path. > >> > >> This is very odd. The CVS version of the code does not contain > >>this file. Do you keep the latest code somewhere else? > >> > >>Gili > >> > Index: ParallelImp.c > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/ParallelImp.c,v > retrieving revision 1.15.2.36 > diff -u -r1.15.2.36 ParallelImp.c > --- ParallelImp.c 11 Feb 2009 01:04:19 -0000 1.15.2.36 > +++ ParallelImp.c 5 Apr 2009 17:55:23 -0000 > @@ -119,7 +119,7 @@ > # include > #endif > > -extern int errno; > +_CRTIMP extern int * __cdecl _errno(void); > > #include "ParallelImp.h" > > @@ -181,8 +181,6 @@ > > #if defined (WIN32) > > -#define CTL_CODE( DeviceType, Function, Method, Access ) (((DeviceType) << 16) | ((Access) << 14) | ((Function) << 2) | (Method)) > - > #define FILE_DEVICE_PARALLEL_PORT 0x00000016 > #define METHOD_BUFFERED 0 > #define FILE_ANY_ACCESS 0 > @@ -253,7 +251,6 @@ > jobject jobj) > { > int fd = get_java_var( env, jobj,"fd","I" ); > - int status; > #if defined (__linux__) > ioctl(fd, LPGETSTATUS, &status); > #elif defined (WIN32) > Index: SerialImp.c > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v > retrieving revision 1.46.2.203 > diff -u -r1.46.2.203 SerialImp.c > --- SerialImp.c 19 Mar 2009 03:27:48 -0000 1.46.2.203 > +++ SerialImp.c 5 Apr 2009 17:49:48 -0000 > @@ -147,7 +147,7 @@ > #include > #endif /* LIBLOCKDEV */ > > -extern int errno; > +_CRTIMP extern int * __cdecl _errno(void); > > #include "SerialImp.h" > > Index: termios.c > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/termios.c,v > retrieving revision 1.9.2.62 > diff -u -r1.9.2.62 termios.c > --- termios.c 13 Jan 2009 03:08:55 -0000 1.9.2.62 > +++ termios.c 5 Apr 2009 17:54:09 -0000 > @@ -88,7 +88,7 @@ > #define SIGIO 0 > > int my_errno; > -extern int errno; > +_CRTIMP extern int * __cdecl _errno(void); > struct termios_list > { > char filename[80]; > @@ -1350,7 +1350,7 @@ > In that case use EAGAIN. See SerialImp.c:testRead() > ----------------------------------------------------------*/ > > -int serial_read( int fd, void *vb, int size ) > +int serial_read( int fd, void *vb, unsigned int size ) > { > long start, now; > unsigned long nBytes = 0, total = 0, error; > Index: win32termios.h > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/win32termios.h,v > retrieving revision 1.5.2.34 > diff -u -r1.5.2.34 win32termios.h > --- win32termios.h 5 Feb 2009 01:25:05 -0000 1.5.2.34 > +++ win32termios.h 5 Apr 2009 20:29:30 -0000 > @@ -60,6 +60,7 @@ > #include > #include > #include > +#include > #ifdef TRACE > #define ENTER(x) report("entering "x" \n"); > #define LEAVE(x) report("leaving "x" \n"); > @@ -70,8 +71,9 @@ > #if defined(_MSC_VER) > #define YACK() \ > { \ > - char *allocTextBuf, message[80]; \ > - unsigned long nChars; \ > + char *allocTextBuf, *message; \ > + const unsigned short longestNumber = 20; \ > + unsigned long nChars, len; \ > unsigned int errorCode = GetLastError(); \ > nChars = FormatMessage ( \ > FORMAT_MESSAGE_ALLOCATE_BUFFER | \ > @@ -82,8 +84,12 @@ > (LPSTR)&allocTextBuf, \ > 16, \ > NULL ); \ > - _snprintf_s( message, 80, 80, "Error 0x%x at %s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); \ > + len = strlen("Error 0x") + longestNumber + strlen(" at ") + strlen(__FILE__) + longestNumber + \ > + strlen(": ") + ((nChars+1) * sizeof(TCHAR)) + 1; \ > + message = malloc(len); \ > + _snprintf_s( message, len, len - 1, "Error 0x%x at %s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); \ > report_error( message ); \ > + free(message); \ > LocalFree(allocTextBuf); \ > Sleep(1); \ > } > @@ -173,7 +179,7 @@ > int serial_test( char * ); > int serial_open(const char *File, int flags, ... ); > int serial_close(int fd); > -int serial_read(int fd, void *b, int size); > +int serial_read(int fd, void *b, unsigned int size); > int serial_write(int fd, char *Str, int length); > /* > * lcc winsock.h conflicts > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx End of message. ------------------------------------------------------------------->8======= About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From bill7007 at gmail.com Mon Apr 6 16:34:50 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Mon, 6 Apr 2009 18:34:50 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: <49D693BA.8060909@gatworks.com> References: <49D546F8.20807@gatworks.com> <49D693BA.8060909@gatworks.com> Message-ID: Once it hung, three stack dumps minutes apart were exactly the same. I have a noticed that when it hangs, the read appears after flush() enter and before flush leave() that doesn't happen like: RXTXPort:SerialOutputStream:flush() enter RXTXPort:SerialInputStream:read(8192 0 8192) called When it works, flush() enter and leave happen together. It may just be because flush() hangs and read is the only other thread waiting to run at that point. I don't know much about the RXTX design and kernel interaction, just digging through the code some. Is there a design description somewhere? Am hung up on target system compile since UTS_RELEASE seems no longer defined for 2.6.18 up kernels and have not figured a good patch yet. But, that is another issue. Thanks for the good help. On Fri, Apr 3, 2009 at 6:54 PM, U. George wrote: > I would have tried 2 or 3 "^\" . If things are stuck, then all will be at > same 'java' instruction. If thread is moving, then one of the snapshots > would be different. > > I *think* flushing/draining wont return until the kernel buffers to device > have been accepted by device. Stuck/paused device? > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090406/c4b509d8/attachment-0012.html From tjarvi at qbang.org Mon Apr 6 17:45:38 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 6 Apr 2009 17:45:38 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <20090406085347.GM8289@elberon.bln.de.ingenico.com> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> <49D919A7.1070806@bbs.darktech.org> <20090406085347.GM8289@elberon.bln.de.ingenico.com> Message-ID: The error bits in the patch can probably just be dropped out. I don't see what they solve. Your snprintf define appears to work. The following is what I'd like to put in if noone objects. #if defined(_MSC_VER) # define snprintf _snprintf #endif #define YACK() \ { \ char *allocTextBuf, message[80]; \ unsigned long nChars; \ unsigned int errorCode = GetLastError(); \ nChars = FormatMessage ( \ FORMAT_MESSAGE_ALLOCATE_BUFFER | \ FORMAT_MESSAGE_FROM_SYSTEM, \ NULL, \ errorCode, \ MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT), \ (LPSTR)&allocTextBuf, \ 16, \ NULL ); \ snprintf( message, 80, "Error 0x%x at %s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); \ message[sizeof(message)-1] = '\0'; /* needed for MS CRT snprintf */ \ report_error( message ); \ LocalFree(allocTextBuf); \ Sleep(1); \ } On Mon, 6 Apr 2009, Steffen DETTMER wrote: > Hi, > > just two minor details, first about the errno change, I though > > #include > extern int errno; > > is correct (POSIX.1) - why this change? > > second about the log message, I think the maximum length could be > limited and the return value of malloc must be checked for != > NULL before using. > > Should it be > > _snprintf_s( message, 80, _TRUNCATE, "Error 0x%x at %s(%d): %s\n", > errorCode, __FILE__, __LINE__, allocTextBuf); > > (I know that MS-CRT _snprintf does not guarantee to have a final > EOS, but I think _snprintf_s with _TRUNCATE does so?). > > If it is known that truncation may happen maybe sizeof[message] > could be increased; maybe using some %.20s could be used avoiding > __FILE__ including big pathes to a message where all the message > had been cut-off. > > To have it portable I think it could be: > > /* generally: */ > #if defined(_MSC_VER) > # define snprintf _snprintf > #endif > > snprintf(message, sizeof(message), "Error 0x%x at %.20s(%d): %s\n", > errorCode, __FILE__, __LINE__, allocTextBuf); > message[sizeof(message)-1] = '\0'; /* needed for MS CRT snprintf */ > > (for length and size parameter I think size_t could be an option, > but on several platforms, including MS-CRT and older glibc, > there is no %z, unfortunately) > > oki, > > Steffen > > > * cowwoc wrote on Sun, Apr 05, 2009 at 16:50 -0400: >> >> Okay, I tracked down the crash. It's being caused by YACK() using a >> 80-character buffer. The error message is longer than 80 characters, so >> _snprintf_s() crashes to avoid a buffer overflow. >> >> Please apply the attached patch and add the zipped up Visual Studio >> project directory. It's not perfect yet but it's a good start. >> >> Gili >> >> Trent Jarvi wrote: >> > >> >CVS HEAD is currently the rxtx 2.0 code. A branch was created long >> >ago for 'experimental' gnu.io work. It just happens that the branch >> >is what everyone uses now. >> > >> >checkout -r commapi-0-0-1 rxtx-devel >> > >> >will get the branch >> > >> >On Sun, 5 Apr 2009, cowwoc wrote: >> > >> >>Trent Jarvi wrote: >> >>>It will compile with the msvc cl.exe and nmake. See Makefile.msvc >> >>>in the top level directory. You will need to adjust the JAVA_HOME >> >>>variable. Also use the MSVC command prompt for x86_64 so cl and >> >>>nmake are on your path. >> >> >> >> This is very odd. The CVS version of the code does not contain >> >>this file. Do you keep the latest code somewhere else? >> >> >> >>Gili >> >> > >> Index: ParallelImp.c >> =================================================================== >> RCS file: /usr/local/cvsroot/rxtx-devel/src/ParallelImp.c,v >> retrieving revision 1.15.2.36 >> diff -u -r1.15.2.36 ParallelImp.c >> --- ParallelImp.c 11 Feb 2009 01:04:19 -0000 1.15.2.36 >> +++ ParallelImp.c 5 Apr 2009 17:55:23 -0000 >> @@ -119,7 +119,7 @@ >> # include >> #endif >> >> -extern int errno; >> +_CRTIMP extern int * __cdecl _errno(void); >> >> #include "ParallelImp.h" >> >> @@ -181,8 +181,6 @@ >> >> #if defined (WIN32) >> >> -#define CTL_CODE( DeviceType, Function, Method, Access ) (((DeviceType) << 16) | ((Access) << 14) | ((Function) << 2) | (Method)) >> - >> #define FILE_DEVICE_PARALLEL_PORT 0x00000016 >> #define METHOD_BUFFERED 0 >> #define FILE_ANY_ACCESS 0 >> @@ -253,7 +251,6 @@ >> jobject jobj) >> { >> int fd = get_java_var( env, jobj,"fd","I" ); >> - int status; >> #if defined (__linux__) >> ioctl(fd, LPGETSTATUS, &status); >> #elif defined (WIN32) >> Index: SerialImp.c >> =================================================================== >> RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v >> retrieving revision 1.46.2.203 >> diff -u -r1.46.2.203 SerialImp.c >> --- SerialImp.c 19 Mar 2009 03:27:48 -0000 1.46.2.203 >> +++ SerialImp.c 5 Apr 2009 17:49:48 -0000 >> @@ -147,7 +147,7 @@ >> #include >> #endif /* LIBLOCKDEV */ >> >> -extern int errno; >> +_CRTIMP extern int * __cdecl _errno(void); >> >> #include "SerialImp.h" >> >> Index: termios.c >> =================================================================== >> RCS file: /usr/local/cvsroot/rxtx-devel/src/termios.c,v >> retrieving revision 1.9.2.62 >> diff -u -r1.9.2.62 termios.c >> --- termios.c 13 Jan 2009 03:08:55 -0000 1.9.2.62 >> +++ termios.c 5 Apr 2009 17:54:09 -0000 >> @@ -88,7 +88,7 @@ >> #define SIGIO 0 >> >> int my_errno; >> -extern int errno; >> +_CRTIMP extern int * __cdecl _errno(void); >> struct termios_list >> { >> char filename[80]; >> @@ -1350,7 +1350,7 @@ >> In that case use EAGAIN. See SerialImp.c:testRead() >> ----------------------------------------------------------*/ >> >> -int serial_read( int fd, void *vb, int size ) >> +int serial_read( int fd, void *vb, unsigned int size ) >> { >> long start, now; >> unsigned long nBytes = 0, total = 0, error; >> Index: win32termios.h >> =================================================================== >> RCS file: /usr/local/cvsroot/rxtx-devel/src/win32termios.h,v >> retrieving revision 1.5.2.34 >> diff -u -r1.5.2.34 win32termios.h >> --- win32termios.h 5 Feb 2009 01:25:05 -0000 1.5.2.34 >> +++ win32termios.h 5 Apr 2009 20:29:30 -0000 >> @@ -60,6 +60,7 @@ >> #include >> #include >> #include >> +#include >> #ifdef TRACE >> #define ENTER(x) report("entering "x" \n"); >> #define LEAVE(x) report("leaving "x" \n"); >> @@ -70,8 +71,9 @@ >> #if defined(_MSC_VER) >> #define YACK() \ >> { \ >> - char *allocTextBuf, message[80]; \ >> - unsigned long nChars; \ >> + char *allocTextBuf, *message; \ >> + const unsigned short longestNumber = 20; \ >> + unsigned long nChars, len; \ >> unsigned int errorCode = GetLastError(); \ >> nChars = FormatMessage ( \ >> FORMAT_MESSAGE_ALLOCATE_BUFFER | \ >> @@ -82,8 +84,12 @@ >> (LPSTR)&allocTextBuf, \ >> 16, \ >> NULL ); \ >> - _snprintf_s( message, 80, 80, "Error 0x%x at %s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); \ >> + len = strlen("Error 0x") + longestNumber + strlen(" at ") + strlen(__FILE__) + longestNumber + \ >> + strlen(": ") + ((nChars+1) * sizeof(TCHAR)) + 1; \ >> + message = malloc(len); \ >> + _snprintf_s( message, len, len - 1, "Error 0x%x at %s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); \ >> report_error( message ); \ >> + free(message); \ >> LocalFree(allocTextBuf); \ >> Sleep(1); \ >> } >> @@ -173,7 +179,7 @@ >> int serial_test( char * ); >> int serial_open(const char *File, int flags, ... ); >> int serial_close(int fd); >> -int serial_read(int fd, void *b, int size); >> +int serial_read(int fd, void *b, unsigned int size); >> int serial_write(int fd, char *Str, int length); >> /* >> * lcc winsock.h conflicts >> > > >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > > > > > > > > > > > > End of message. > ------------------------------------------------------------------->8======= > > > About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. > This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > P Please consider the environment before printing this e-mail > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Apr 6 18:11:28 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 6 Apr 2009 18:11:28 -0600 (MDT) Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: <49D546F8.20807@gatworks.com> <49D693BA.8060909@gatworks.com> Message-ID: UTS_RELEASE is defined in now. The check really should be removed from RXTX. It was a defensive check for wilder times when GNU glibc did not have defines the kernel headers had so rxtx would include the kernel headers instead. :/ If you don't have linux/version.h, it is generated when you configure the kernel. make oldconfig used to do the trick. It may make sense to work with the prerelease or CVS code. RXTX just assumes that flush, read and anything else the kernel exposes may be called at anytime from any thread. There isn't a design for the kernel interaction. There are higher level constraints put in Java to prevent some things happening at the same time with 'synchronized.' RXTXPort.java has all of those. When the port is opened, a native event thread is started which uses select to know if an event has happened. BSD like systems have a native thread that fires off on write which tries to flush() to determine when the output buffer is empty asynchronously. The rest is not marshaled in any fashion at the native level. T I think there is a lower level deadlock being triggered in flush as well. I don't think it should be possible if everything was right underneath us. You may want to examine the java code closer to make sure it isnt possible the lock is there. On Mon, 6 Apr 2009, Bill Johnson wrote: > Once it hung, three stack dumps minutes apart were exactly the same. > I have a noticed that when it hangs, the read appears after flush() enter and > before flush leave() that doesn't happen like: > RXTXPort:SerialOutputStream:flush() enter > RXTXPort:SerialInputStream:read(8192 0 8192) called > > When it works, flush() enter and leave happen together. It may just be because > flush() hangs and read is the only other thread waiting to run at that point. > I don't know much about the RXTX design and kernel interaction, just digging > through the code some. Is there a design description somewhere? > > Am hung up on target system compile since UTS_RELEASE seems no longer defined for > 2.6.18 up kernels and have not figured a good patch yet. But, that is another > issue. > > Thanks for the good help. > > > On Fri, Apr 3, 2009 at 6:54 PM, U. George wrote: > I would have tried 2 or 3 "^\" . If things are stuck, then all will be > at same 'java' instruction. If thread is moving, then one of the > snapshots would be different. > > I *think* flushing/draining wont return until the kernel buffers to > device have been accepted by device. Stuck/paused device? > > > > > From tjarvi at qbang.org Mon Apr 6 18:28:50 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 6 Apr 2009 18:28:50 -0600 (MDT) Subject: [Rxtx] CVS updates. Pre3 is comming. Message-ID: I need to go through the bugzilla reports prior to the pre3 release. I think this should be close if you want to check it out from CVS. added: YACK() debug overflow fix for windows Steffen DETTMER (and many others) multiport fix for windows. Ilkka Myller http://mailman.qbang.org/pipermail/rxtx/2009-February/3989441.html I think this code is current. If I missed something, yell. CVS Info: export/setenv CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login # passwd mousy cvs checkout -r commapi-0-0-1 rxtx-devel -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Apr 6 22:32:07 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 6 Apr 2009 22:32:07 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D919A7.1070806@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> <49D919A7.1070806@bbs.darktech.org> Message-ID: Ah. I'll put this in CVS tomorrow. I did sync up the code with my work sandbox today. I just forgot to pull and add this. On Sun, 5 Apr 2009, cowwoc wrote: > > Okay, I tracked down the crash. It's being caused by YACK() using a > 80-character buffer. The error message is longer than 80 characters, so > _snprintf_s() crashes to avoid a buffer overflow. > > Please apply the attached patch and add the zipped up Visual Studio > project directory. It's not perfect yet but it's a good start. > > Gili > > Trent Jarvi wrote: >> >> CVS HEAD is currently the rxtx 2.0 code. A branch was created long ago for >> 'experimental' gnu.io work. It just happens that the branch is what >> everyone uses now. >> >> checkout -r commapi-0-0-1 rxtx-devel >> >> will get the branch >> >> On Sun, 5 Apr 2009, cowwoc wrote: >> >>> Trent Jarvi wrote: >>>> It will compile with the msvc cl.exe and nmake. See Makefile.msvc in the >>>> top level directory. You will need to adjust the JAVA_HOME variable. >>>> Also use the MSVC command prompt for x86_64 so cl and nmake are on your >>>> path. >>> >>> This is very odd. The CVS version of the code does not contain this >>> file. Do you keep the latest code somewhere else? >>> >>> Gili >>> > From cowwoc at bbs.darktech.org Tue Apr 7 06:07:46 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Tue, 07 Apr 2009 08:07:46 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: References: Message-ID: <49DB4212.40807@bbs.darktech.org> > just two minor details, first about the errno change, I though > > #include > extern int errno; > > is correct (POSIX.1) - why this change? If you compile this under Visual Studio 2008 you will get warnings that the errno type being imported is different from the type being exported. The definition I pasted is the one being exported. Perhaps we should use #ifdef WIN32 for this? Gili From bill7007 at gmail.com Tue Apr 7 17:58:54 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Tue, 7 Apr 2009 19:58:54 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: <49D546F8.20807@gatworks.com> <49D693BA.8060909@gatworks.com> Message-ID: I have traced the hang down to a call to tcdrain(fd) in SerialImp.c:drain() running and rebuilt under Netbeans on the target machine with debug messages on. That puts it into the system code, so I'm not sure how to proceed. I guess I could debug into the kernel source but I've not done that. I saw some discussion about an IOCTL that sets/adjusts a timeout on tcdrain() but that may have been for BSD. Maybe there is some new setup requirement or bug introduced with this 2.6.18 kernel or a hardware difference. Below is a message listing with some of the repeated parts removed. Maybe you can see something noteworthy? JNI_OnLoad called. WARNING: RXTX Version mismatch Jar version = RXTX-2.2pre2 native lib Version = RXTX-2.2pre3 entering RXTXCommDriver:getDeviceDirectory entering RXTXPort:testRead fhs_lock: creating lockfile: 29704 fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXPort:testRead RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB2 fhs_lock: creating lockfile: 29704 fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXPort:testRead RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB1 fhs_lock: creating lockfile: 29704 fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXPort:testRead RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB0 fhs_lock: creating lockfile: 29704 fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXPort:testRead fhs_lock: creating lockfile: 29704 ... REPEATS fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXPort:testRead fhs_lock: creating lockfile: 29704 fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXCommDriver:getDeviceDirectory entering RXTXPort:testRead fhs_lock: creating lockfile: 29704 ...REPEATS fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXPort:testRead fhs_lock: creating lockfile: 29704 fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXPort:Initialize RXTX WARNING: This library was compiled to run with OS release 2.6.18 and you are currently running OS release 2.6.18-92.1.6.el5. In some cases this can be a problem. Try recompiling RXTX if you notice strange behavior. If you just compiled RXTX make sure /usr/include/linux is a symbolic link to the include files that came with the kernel source and not an older copy. press enter to continue leaving RXTXPort:Initialize entering RXTXPort:open fhs_lock: creating lockfile: 29704 open: locking worked for /dev/ttyUSB2 open: fd returned is 9 leaving RXTXPort:open entering eventLoop has_line_status_register_acess: Port does not support TIOCSERGETLSR driver_has_tiocgicount: Port does not support TIOCGICOUNT events init_threads: get eis init_threads: set eis init_threads: stop leaving RXTXPort:translate_speed entering RXTXPort:nativeSetSerialPortParams entering translate_date_bits entering translate_stop_bits leaving RXTXPort:translate_stop_bits entering translate_parity leaving translate_parity entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 ...REPEATS entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 leaving RXTXPort:nativeSetSerialPortParams entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 ...REPEATS entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 entering writeArray entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 writeArray() leaving RXTXPort:writeArray entering SerialImp.c:drain() nativeDrain: trying tcdrain RXTXPort:drain() returns: 0 leaving RXTXPort:drain() entering writeArray writeArray() leaving RXTXPort:writeArray entering SerialImp.c:drain() nativeDrain: trying tcdrain entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 Tue Apr 07 18:51:49 EDT 2009:TSerial[22]:Using Port:/dev/ttyUSB2 Tue Apr 07 18:51:49 EDT 2009:TSerial[22].Transmit:TN Tue Apr 07 18:51:49 EDT 2009:TSerial[22].Transmit:RV entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 ...REPEATS FOREVER? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090407/f26e5752/attachment-0011.html From tjarvi at qbang.org Tue Apr 7 18:31:23 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 7 Apr 2009 18:31:23 -0600 (MDT) Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: <49D546F8.20807@gatworks.com> <49D693BA.8060909@gatworks.com> Message-ID: On Tue, 7 Apr 2009, Bill Johnson wrote: > I have traced the hang down to a call to tcdrain(fd) in SerialImp.c:drain() > running and rebuilt under Netbeans on the target machine with debug messages > on. That puts it into the system code, so I'm not sure how to proceed. I > guess I could debug into the kernel source but I've not done that. I saw > some discussion about an IOCTL that sets/adjusts a timeout on tcdrain() but > that may have been for BSD. Maybe there is some new setup requirement or bug > introduced with this 2.6.18 kernel or a hardware difference. > Below is a message listing with some of the repeated parts removed. Maybe > you can see something noteworthy? > > JNI_OnLoad called. > WARNING:? RXTX Version mismatch > ??????? Jar version = RXTX-2.2pre2 > ??????? native lib Version = RXTX-2.2pre3 > entering RXTXCommDriver:getDeviceDirectory > entering RXTXPort:testRead > fhs_lock: creating lockfile:????? 29704 > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXPort:testRead > RXTX Warning:? Removing stale lock file. /var/lock/LCK..ttyUSB2 > fhs_lock: creating lockfile:????? 29704 > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXPort:testRead > RXTX Warning:? Removing stale lock file. /var/lock/LCK..ttyUSB1 > fhs_lock: creating lockfile:????? 29704 > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXPort:testRead > RXTX Warning:? Removing stale lock file. /var/lock/LCK..ttyUSB0 > fhs_lock: creating lockfile:????? 29704 > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXPort:testRead > fhs_lock: creating lockfile:????? 29704 > > ... REPEATS > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXPort:testRead > fhs_lock: creating lockfile:????? 29704 > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXCommDriver:getDeviceDirectory > entering RXTXPort:testRead > fhs_lock: creating lockfile:????? 29704 > > ...REPEATS > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXPort:testRead > fhs_lock: creating lockfile:????? 29704 > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXPort:Initialize > > > > RXTX WARNING:? This library was compiled to run with OS release 2.6.18 and > you are currently running OS release 2.6.18-92.1.6.el5.? In some cases this > can be a problem.? Try recompiling RXTX if you notice strange behavior.? If > you just compiled RXTX make sure /usr/include/linux is a symbolic link to > the include files that came with the kernel source and not an older copy. > > > press enter to continue > > leaving RXTXPort:Initialize > entering RXTXPort:open > fhs_lock: creating lockfile:????? 29704 > > open: locking worked for /dev/ttyUSB2 > open: fd returned is 9 > leaving RXTXPort:open > entering eventLoop > ? > has_line_status_register_acess: Port does not support TIOCSERGETLSR > ?driver_has_tiocgicount:? Port does not support TIOCGICOUNT events > init_threads: get eis > init_threads: set eis > init_threads:? stop > leaving RXTXPort:translate_speed > entering RXTXPort:nativeSetSerialPortParams > entering translate_date_bits > entering translate_stop_bits > leaving RXTXPort:translate_stop_bits > entering translate_parity > leaving translate_parity > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > ...REPEATS > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > leaving RXTXPort:nativeSetSerialPortParams > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > ...REPEATS > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > entering writeArray > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > writeArray() > leaving RXTXPort:writeArray > entering SerialImp.c:drain() > nativeDrain: trying tcdrain > RXTXPort:drain() returns: 0 > leaving RXTXPort:drain() > entering writeArray > writeArray() > leaving RXTXPort:writeArray > entering SerialImp.c:drain() > nativeDrain: trying tcdrain > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > Tue Apr 07 18:51:49 EDT 2009:TSerial[22]:Using Port:/dev/ttyUSB2 > Tue Apr 07 18:51:49 EDT 2009:TSerial[22].Transmit:TN > > Tue Apr 07 18:51:49 EDT 2009:TSerial[22].Transmit:RV > > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > ...REPEATS FOREVER? > > > Hi Bill ugh. The tiocmget... is the eventLoop checking for events. It sits with select() but has a timeout value to keep it spinning at a trivial rate. tcdrain() is the suspect. I don't see anything in the code that looks like a problem. If flow control is not enabled, I don't see a reason for it not to return. Given that this is USB, perhaps a message from the device got lost. Onboard UARTs would have a status register change when output buffer is empty. USB needs to communicate the event as an HID device which may be the source of the error. Dropping back to onboard UARTs eliminates that portion of the mix. What vendor/chipset is the USB dongle? I understand code has been pushed upon the linux serial devices for new for things like acpi. There very well could be a bug introduced. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Apr 7 18:38:22 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 7 Apr 2009 18:38:22 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49DB4212.40807@bbs.darktech.org> References: <49DB4212.40807@bbs.darktech.org> Message-ID: On Tue, 7 Apr 2009, cowwoc wrote: >> just two minor details, first about the errno change, I though >> >> #include >> extern int errno; >> >> is correct (POSIX.1) - why this change? > > If you compile this under Visual Studio 2008 you will get warnings that > the errno type being imported is different from the type being exported. > The definition I pasted is the one being exported. Perhaps we should use > #ifdef WIN32 for this? > Hi Gili, Perhaps a workaround for _MSVC is in order. GNU compilers for windows won't complain. If it's a question of MSVC or POSIX being right, the library favors the standard as a stated goal. I'm not sure what MSVC is using errno for but it should not be using it except with POSIX extensions. Perhaps #undef is enough to get rid of the warning and (maybe) has no ill consequences. Newer windows have POSIX extensions that may show how Microsoft solved the problem. It can probably fester. -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Tue Apr 7 19:54:06 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Tue, 07 Apr 2009 21:54:06 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: References: <49DB4212.40807@bbs.darktech.org> Message-ID: <49DC03BE.5010203@bbs.darktech.org> Trent Jarvi wrote: > I'm not sure what MSVC is using errno for but it should not be using it > except with POSIX extensions. Perhaps #undef is enough to get rid of > the warning and (maybe) has no ill consequences. Newer windows have > POSIX extensions that may show how Microsoft solved the problem. > > It can probably fester. What does "newer windows" refer to in this case? I was compiling using Visual Studio 2008 sp1 under Windows Vista. Both are cutting edge technologies as far as official releases go. I think you're best suited to judge whether this warning is a big deal or not so I think you should see it for yourself. Please try firing up Visual Studio 2008 (express?) against the project I sent you. Gili From Steffen.DETTMER at ingenico.com Wed Apr 8 05:50:42 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 8 Apr 2009 13:50:42 +0200 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49DC03BE.5010203@bbs.darktech.org> References: <49DB4212.40807@bbs.darktech.org> <49DC03BE.5010203@bbs.darktech.org> Message-ID: <20090408115042.GC5090@elberon.bln.de.ingenico.com> * cowwoc wrote on Tue, Apr 07, 2009 at 21:54 -0400: > Trent Jarvi wrote: > > I'm not sure what MSVC is using errno for but it should not be using it > > except with POSIX extensions. Perhaps #undef is enough to get rid of > > the warning and (maybe) has no ill consequences. Newer windows have > > POSIX extensions that may show how Microsoft solved the problem. I think here best is simply to omit this old^Wclassic `extern int errno;' line completely. I think standards just say something like `implementations may support the declaration extern int errno;'. About POSIX extensions I think in general it should be considered that althrough many things are available, even with MS Visual C++, the Microsoft tools lead developers to write non-portable code (and personally I think this is intentional). For example, they call the official ISO-C function `strerror' deprecated (!) and twaddle about some security enhancements (without even beeing specific). Someone could, because of this, lead to use the MS specific, unportable `strerror_s' instead. Even better, at _strerror_s they tell, for `ANSI compatiblity someone should use strerror_s'. Of course a program using [_]strerror_s won't be ANSI-C compliant. Do they mean strerror_r? _strerror_s has the same parameters - but of course in different order - to make porting a pain... SCNR. > What does "newer windows" refer to in this case? I was compiling using > Visual Studio 2008 sp1 under Windows Vista. Both are cutting edge > technologies as far as official releases go. `cutting edge technologies' yeah post-standard, portability-cutting technologies smoothing the way to MS world domination; own post-ANSI-C programming languages help (maybe to increase the share holder value)... SCNR. > I think you're best suited to judge whether this warning is a big deal > or not so I think you should see it for yourself. Please try firing up > Visual Studio 2008 (express?) against the project I sent you. yeah, getting the CL.EXE of 2008 running in a normal command line environment (without its special `C++ Shell') is a bit tricky - but possible. ;) oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From tjarvi at qbang.org Wed Apr 8 14:29:54 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 8 Apr 2009 14:29:54 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49DC03BE.5010203@bbs.darktech.org> References: <49DB4212.40807@bbs.darktech.org> <49DC03BE.5010203@bbs.darktech.org> Message-ID: The support has been around for a long time to. I don't know the details but the support appears to be tied to the OS. http://en.wikipedia.org/wiki/POSIX#POSIX_for_Windows On Tue, 7 Apr 2009, cowwoc wrote: > Trent Jarvi wrote: >> I'm not sure what MSVC is using errno for but it should not be using it >> except with POSIX extensions. Perhaps #undef is enough to get rid of the >> warning and (maybe) has no ill consequences. Newer windows have POSIX >> extensions that may show how Microsoft solved the problem. >> >> It can probably fester. > > What does "newer windows" refer to in this case? I was compiling > using Visual Studio 2008 sp1 under Windows Vista. Both are cutting edge > technologies as far as official releases go. > > I think you're best suited to judge whether this warning is a big > deal or not so I think you should see it for yourself. Please try firing up > Visual Studio 2008 (express?) against the project I sent you. > > Gili > From bill7007 at gmail.com Wed Apr 8 15:59:08 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Wed, 8 Apr 2009 17:59:08 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: <49D546F8.20807@gatworks.com> <49D693BA.8060909@gatworks.com> Message-ID: Hi Trent, I think I have hit on a work around but don't know why it works. The USB serial adapter is a "CableMAX" based on Prolific's PL2303. Backing out to the big picture, the application is old and has been very reliable until put on a new cpu and kernel. It only hangs sometimes say 25% and always at the same place, at tcdrain() on the flush() after the second write after startup. If it made it past this stage, all transmit and receive seemed reliable so it was like a startup timing issue. Since learning to debug kernel code is beyond my immediate priority, I took a shot at moving code around, adding delays, and such. I have found it good practice to do a flush after every write on streams like: outputStream.write(data.getBytes()); outputStream.flush(); If I remove the flush() after each write, the problem appears to go away! I don't think the flush is needed for a SerialOutputStream for this application anyway. Thanks for all the help, +BillJ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090408/35d96a9d/attachment-0010.html From bill7007 at gmail.com Thu Apr 9 09:20:11 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Thu, 9 Apr 2009 11:20:11 -0400 Subject: [Rxtx] Baud rate fixes in 2.2pre2 breaks 38400 on some Linux devices Message-ID: Hello, An application that worked at 38400 on a USB serial adapter (PL2303) using 2.1-7-r2 on Linux EL4 (and EL5) now fails using 2.2pre2. serialPort.setSerialPortParams(38400,SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); throws an unsupportedCommOperationException This problem matched a description of Bug 113and I posted a proposed patch there, but I don't understand the whole custom baud rate patch so it may need some thought. An older patch, [Rxtx] [Patch]: Baud Rate fixes try 1, testing encouraged., fixed some custom baud rates but apparently broke 38400 on some Linux device. Other baud rates seem to work OK. And, 38400 tested OK on local non-USB ports. My proposed patch probably breaks the custom baud rate patch since it was keyed on 38400 as a special case for Linux and my fix was to back out part of that patch, specifically: #if defined(TIOCGSERIAL) if ( cspeed == B38400 ) cspeed = 38400; #endif /* TIOCGSERIAL */ +BillJ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090409/5636af64/attachment-0009.html From cowwoc at bbs.darktech.org Fri Apr 10 08:38:49 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Fri, 10 Apr 2009 10:38:49 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: References: <49DB4212.40807@bbs.darktech.org> <49DC03BE.5010203@bbs.darktech.org> Message-ID: <49DF59F9.2050408@bbs.darktech.org> Doesn't Wikipedia list as an optional sub-system? Gili Trent Jarvi wrote: > > The support has been around for a long time to. I don't know the > details but the support appears to be tied to the OS. > > http://en.wikipedia.org/wiki/POSIX#POSIX_for_Windows > > On Tue, 7 Apr 2009, cowwoc wrote: > >> Trent Jarvi wrote: >>> I'm not sure what MSVC is using errno for but it should not be using >>> it except with POSIX extensions. Perhaps #undef is enough to get >>> rid of the warning and (maybe) has no ill consequences. Newer >>> windows have POSIX extensions that may show how Microsoft solved the >>> problem. >>> >>> It can probably fester. >> >> What does "newer windows" refer to in this case? I was compiling >> using Visual Studio 2008 sp1 under Windows Vista. Both are cutting >> edge technologies as far as official releases go. >> >> I think you're best suited to judge whether this warning is a big >> deal or not so I think you should see it for yourself. Please try >> firing up Visual Studio 2008 (express?) against the project I sent you. >> >> Gili >> From eranshuman at gmail.com Mon Apr 13 04:50:34 2009 From: eranshuman at gmail.com (Anshuman Srivastava) Date: Mon, 13 Apr 2009 16:20:34 +0530 Subject: [Rxtx] Send RTS /DTR signal Message-ID: <589913a50904130350n59cc51ffvbcd0a4eaefb4ce5f@mail.gmail.com> Hi, I want to send the RTS or DTR signal from the application Can anybody telll how to send the DTR /RTS signal using rxtxcomm libraries Thanks and regards -- Anshuman Srivastava "... in the end, it's not the years in your life that count. It's the life in your years." Buzz +91 9962515155 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090413/211b5ded/attachment-0006.html From ajmas at sympatico.ca Mon Apr 13 09:50:47 2009 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 13 Apr 2009 11:50:47 -0400 Subject: [Rxtx] Wiki Spam pages - need of captcha? Message-ID: Hi Trent, While checking for spam pages in the wiki I came across a page containing the following: "NOTICE: This page was created by a program as part of the Graffiti Network research project at Brown University. We have removed the data, but are unable to remove this page. We apologize for any inconveniences that our actions may have caused. For more information, please visit http://graffiti.cs.brown.edu/info/." Is there any chance we could add a captcha to account registration? Andr?-John From sguido at micromotive.net Mon Apr 13 09:46:15 2009 From: sguido at micromotive.net (Samuel Guido) Date: Mon, 13 Apr 2009 11:46:15 -0400 Subject: [Rxtx] Serial Output Stream Hangs on Windows Message-ID: <843C9F1C-72EE-4A40-B02A-3798EB0C57BF@micromotive.net> All, I am using RXTX in a small application to talk to a remote embedded device on a Windows host. All data is ASCII text. On physical comm ports, everything seems to be fine, messages are sent and received without much trouble. I am also trying to make the comm port selection automatic where I cycle through the available comm ports sending messages until I get the expected response. Unfortunately, when I query for the available comm ports, the bluetooth ports also show up. Whenever I try to send a string of characters to the bluetooth port, RXTX hangs way down in the call stack in the output stream, I believe in the DLL. I tried both the 2.1.7r2 and the 2.2pre2 releases and both have the same result. The send and receiving of messages from the comm port are in their own threads, but once the thread is blocked, I can't do anything with the comm ports since they are synchronized calls. The bluetooth ports are using a driver call "WIDCOMM" which I don't know who/what that is. This is on a IBM T42 laptop machine. Does anyone know what could be causing this? Is there a way to distinguish between bluetooth ports and physical comm ports? Please help, I am on a tight deadline and any help would greatly be appreciated. Thanks very much. Sam Guido From ajmas at sympatico.ca Mon Apr 13 11:04:24 2009 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 13 Apr 2009 13:04:24 -0400 Subject: [Rxtx] RxTX mentioned on Sun's Java Communications page Message-ID: Looks like RxTx gets some mention at Sun: Head over to the Java Communications page http://java.sun.com/products/javacomm/ and then click on Downloads and you get: " COMM API is a Java extension providing access to RS-232 serial ports and IEEE-1284 parallel ports (SPP mode). Sun Ray platform support is provided. Documentation and sample code are included, as well as interactive test utilities. API serial features provide access to: * Port settings (baud rate, parity, stop bits) * Port naming, mapping, enumeration (configurable) * Data transfer over TX, RX lines * DTR, CD, CTS, RTS and DSR signals * Hardware/Software flow-control * Receive-buffer threshold control * Asynchronous events indicating: * Data available on an RS-232 port * Port hardware line level changes * Port ownership changes within a JVM Update History: * javax.comm 3.0, Update 1 o Fixed problems locating and parsing portmap.conf * javax.comm 3.0, FCS o Redesigned portmapping and Sun Ray interoperability (see bundled documentation) * 2.0.3: o Added portmapping (comm.jar available 'as-is' for 3rd party native lib support)* Several Bugfixes to 2.0.3 (see bundled release notes) Note: Sun no longer offer's the Windows platform binaries of javax.comm, however javax.comm 2.0.3 can be used for the Windows platform, by using it in conjunction with the Win32 implementation layer provided by the RxTx project. To use that, download javax.comm for the 'generic' platform (which provides the front-end javax.comm API only, without platform specific back-end implementations bundled). Then acquire the Windows binary implementation rxtx-2.0.7pre1 from http://www.rxtx.org . " Looks like RxTx really is the closest thing we have to the 'official' implementation. From tjarvi at qbang.org Mon Apr 13 12:27:44 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 13 Apr 2009 12:27:44 -0600 (MDT) Subject: [Rxtx] RxTX mentioned on Sun's Java Communications page In-Reply-To: References: Message-ID: On Mon, 13 Apr 2009, Andre-John Mas wrote: > Looks like RxTx gets some mention at Sun: > > Head over to the Java Communications page http://java.sun.com/products/javacomm/ > and then click on Downloads and you get: > > " > COMM API is a Java extension providing access to RS-232 serial ports > and IEEE-1284 parallel ports (SPP mode). Sun Ray platform support is > provided. Documentation and sample code are included, as well as > interactive test utilities. API serial features provide access to: * > Port settings (baud rate, parity, stop bits) * Port naming, mapping, > enumeration (configurable) * Data transfer over TX, RX lines * DTR, > CD, CTS, RTS and DSR signals * Hardware/Software flow-control * > Receive-buffer threshold control * Asynchronous events indicating: * > Data available on an RS-232 port * Port hardware line level changes * > Port ownership changes within a JVM Update History: * javax.comm 3.0, > Update 1 o Fixed problems locating and parsing portmap.conf * > javax.comm 3.0, FCS o Redesigned portmapping and Sun Ray > interoperability (see bundled documentation) * 2.0.3: o Added > portmapping (comm.jar available 'as-is' for 3rd party native lib > support)* Several Bugfixes to 2.0.3 (see bundled release notes) Note: > Sun no longer offer's the Windows platform binaries of javax.comm, > however javax.comm 2.0.3 can be used for the Windows platform, by > using it in conjunction with the Win32 implementation layer provided > by the RxTx project. To use that, download javax.comm for the > 'generic' platform (which provides the front-end javax.comm API only, > without platform specific back-end implementations bundled). Then > acquire the Windows binary implementation rxtx-2.0.7pre1 from http://www.rxtx.org > .. > " > > Looks like RxTx really is the closest thing we have to the 'official' > implementation. Ugh. I don't know of any developer interest in maintaining rxtx 2.0. It would be cleaner for Sun to just openly take javax.comm for their Sun Ray project. If someone is interested in maintaining rxtx 2.0, don't be afraid to say so. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Mon Apr 13 16:04:19 2009 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 13 Apr 2009 17:04:19 -0500 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D8DDEB.5010908@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> Message-ID: <49E3B6E3.5050203@cox.net> cowwoc wrote: > Trent Jarvi wrote: >> You are responsible for cleaning up the serial ports when using threads. >> That said, if the thread did shut down, finalize should have been called >> if you are not passing the object around. See RXTXPort.java. >> >> protected void finalize() >> { >> if (debug) >> z.reportln( "RXTXPort:finalize()"); >> if( fd > 0 ) >> { >> if (debug) >> z.reportln( "RXTXPort:calling close()"); >> close(); >> } >> z.finalize(); >> } > > Two points: > > 1) One should never rely on finalizers because they may never run. A PhantomRef is the way to do this kind of cleanup in most cases. It will always fire. The real issue is that you have to understand that the on the Sun JVM, the GC can run finalization or advertise a dropped reference before an object is actually unreferenced in some cases. This happens, predominately in blocks of code where object references are short lived with no class member reference that the GC can find. When the JIT compiled code just references an object on the local stack and/or a register, the GC can prematurely attempt finalization/PhantomRef notification and result in bad things happening. The single solution to this problem is to use synchronize(obj){} at the end of the block of code that obj lives in, which keeps the object from getting reclaimed prematurely. For the sake of application sanity and recovery from erroneous code, it's almost always best to put resources like this into a map, accessed by name, and make an API method that lets you find the object by name, rather than by instance reference. Then, in your code, when you want to open a serial port, you'd do something like the following, which will close anything you already opened and then open it back up. Map ports = ...; public void closePort( String port ) { CommPort p = null; p = ports.remove(port); if( p != null ) p.close(); } public CommPort public CommPort openPort( String port, String user, int timeout ) throws IOException { closePort( port ); CommPort p = CommPortIdentifier.getPortIdentifier(port). open( user, timeout ); ports.put( port, p ); return p; } Appropriate use of synchronized(ports) may be necessary if ports is not referencing a concurrency safe Map implementation such as Hashtable or ConcurrentHashMap. Gregg Wonderly From gergg at cox.net Mon Apr 13 16:36:57 2009 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 13 Apr 2009 17:36:57 -0500 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: <49D546F8.20807@gatworks.com> <49D693BA.8060909@gatworks.com> Message-ID: <49E3BE89.4020402@cox.net> Check CTS/RTS and DTR/CD etc on the device to make sure you haven't hung the kernel trying to clean up something, but it's now waiting for CTS etc. In general, you should be careful about using HW flow control when cables can be trivially unplugged or broken. Use application layer checksums or similar things to make sure data that is flowing is sane and that buffers have not overrun, resulting in lost data. Gregg Wonderly Trent Jarvi wrote: > UTS_RELEASE is defined in now. The check really should > be removed from RXTX. It was a defensive check for wilder times when GNU > glibc did not have defines the kernel headers had so rxtx would include > the kernel headers instead. :/ > > If you don't have linux/version.h, it is generated when you configure the > kernel. make oldconfig used to do the trick. It may make sense to work > with the prerelease or CVS code. > > RXTX just assumes that flush, read and anything else the kernel exposes > may be called at anytime from any thread. There isn't a design for the > kernel interaction. There are higher level constraints put in Java to > prevent some things happening at the same time with 'synchronized.' > RXTXPort.java has all of those. > > When the port is opened, a native event thread is started which uses > select to know if an event has happened. > > BSD like systems have a native thread that fires off on write which tries > to flush() to determine when the output buffer is empty asynchronously. > > The rest is not marshaled in any fashion at the native level. T > > I think there is a lower level deadlock being triggered in flush as well. > I don't think it should be possible if everything was right underneath us. > You may want to examine the java code closer to make sure it isnt possible > the lock is there. > > > On Mon, 6 Apr 2009, Bill Johnson wrote: > >> Once it hung, three stack dumps minutes apart were exactly the same. >> I have a noticed that when it hangs, the read appears after flush() enter and >> before flush leave() that doesn't happen like: >> RXTXPort:SerialOutputStream:flush() enter >> RXTXPort:SerialInputStream:read(8192 0 8192) called >> >> When it works, flush() enter and leave happen together. It may just be because >> flush() hangs and read is the only other thread waiting to run at that point. >> I don't know much about the RXTX design and kernel interaction, just digging >> through the code some. Is there a design description somewhere? >> >> Am hung up on target system compile since UTS_RELEASE seems no longer defined for >> 2.6.18 up kernels and have not figured a good patch yet. But, that is another >> issue. >> >> Thanks for the good help. >> >> >> On Fri, Apr 3, 2009 at 6:54 PM, U. George wrote: >> I would have tried 2 or 3 "^\" . If things are stuck, then all will be >> at same 'java' instruction. If thread is moving, then one of the >> snapshots would be different. >> >> I *think* flushing/draining wont return until the kernel buffers to >> device have been accepted by device. Stuck/paused device? >> >> >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From cowwoc at bbs.darktech.org Mon Apr 13 20:41:20 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Mon, 13 Apr 2009 22:41:20 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49E3B6E3.5050203@cox.net> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49E3B6E3.5050203@cox.net> Message-ID: <49E3F7D0.5090207@bbs.darktech.org> Gregg Wonderly wrote: > A PhantomRef is the way to do this kind of cleanup in most cases. It > will always fire. The real issue is that you have to understand that > the on the Sun JVM, the GC can run finalization or advertise a dropped > reference before an object is actually unreferenced in some cases. This > happens, predominately in blocks of code where object references are > short lived with no class member reference that the GC can find. When > the JIT compiled code just references an object on the local stack > and/or a register, the GC can prematurely attempt > finalization/PhantomRef notification and result in bad things happening. I've never seen this myself. Can you reproduce it on the latest JRE? If so, this sounds like a bug to me and should be fixed. Please consider filing a bug report and telling me the bug number. I'll try running it by my Sun contacts. Gili From ferry_new2004 at yahoo.com Mon Apr 13 21:24:59 2009 From: ferry_new2004 at yahoo.com (Ferry Sumendap) Date: Mon, 13 Apr 2009 20:24:59 -0700 (PDT) Subject: [Rxtx] In Linux, RXTX serial port lib cannot send character which hex is more than 127. Message-ID: <30875.39589.qm@web33106.mail.mud.yahoo.com> Hello everybody, I have just tested the RXTXserial port library version RXTX2-1-7pre20 to send two characters which are character ascii 230 and 234. It seems that the driver somehow did not send the two characters into serial port if the Operating System is Linux Mandriva 2007 (kernel version 2.6.17-13mdv ) or Linux Mandriva 2009. I also tried the driver using same java code (java class file of the program I wrote), in Windows XP, it does work. Should I configure something (special configuration in Linux) or did I miss something ? I also have tested the latest RXTX 2.2pre2 driver, but it still have that problem. Regards, Ferry -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090413/94fdfbea/attachment-0005.html From tjarvi at qbang.org Mon Apr 13 22:01:04 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 13 Apr 2009 22:01:04 -0600 (MDT) Subject: [Rxtx] In Linux, RXTX serial port lib cannot send character which hex is more than 127. In-Reply-To: <30875.39589.qm@web33106.mail.mud.yahoo.com> References: <30875.39589.qm@web33106.mail.mud.yahoo.com> Message-ID: On Mon, 13 Apr 2009, Ferry Sumendap wrote: > Hello everybody, > > I have just tested the RXTXserial port library version? RXTX2-1-7pre20 to > send two characters which are character ascii? 230 and 234. It seems that > the driver somehow did not send the two characters into serial port if the > Operating System is Linux Mandriva 2007 (kernel version 2.6.17-13mdv > ) or Linux Mandriva 2009. > I also tried the driver using? same java code (java class file of the > program I wrote), in Windows XP,? it does work. > > Should I configure something (special configuration in Linux)? or did I miss > something ? > I also have tested the latest RXTX 2.2pre2 driver, but it still have that > problem. > Hello Ferry This sounds like an unlikely problem. Even with USB dongle issues, I can't think of a reason that would be a problem. Is this a connection at 9600 8N1? Sometimes it really is the cable. -- Trent Jarvi tjarvi at qbang.org From ferry_new2004 at yahoo.com Mon Apr 13 22:15:04 2009 From: ferry_new2004 at yahoo.com (Ferry Sumendap) Date: Mon, 13 Apr 2009 21:15:04 -0700 (PDT) Subject: [Rxtx] Fw: In Linux, RXTX serial port lib cannot send character which hex is more than 127. Message-ID: <948418.50805.qm@web33103.mail.mud.yahoo.com> ----- Forwarded Message ---- From: Ferry Sumendap To: Trent Jarvi Sent: Tuesday, April 14, 2009 11:10:04 AM Subject: Re: [Rxtx] In Linux, RXTX serial port lib cannot send character which hex is more than 127. Thank you for your answer. I use the same machine, cable and devices to test. My PC is installed with Linux Mandriva and WINDOWS. The serial port physically have no problem since using Windows, it works. I also tested the serial port using MONI (tcl based program). MONI is linux based program to send some characters to serial port. Using MONI, I sent the characters to /dev/ttyS0, and it works because the device which is plugged in /dev/ttyS0 received and answered the message. But for RXTX, some how, java based program cannot send those characters. With the same java based program, it works properly in WINDOWS and the same cable, devices, hardware specification. That's why I am curious about RXTX. Here is the serial port configuration I used. Com Port /dev/ttyS0 Baud rate 19200 Data bits 8 ( value = 8) Stop bits 1 ( value = 1) Parity None ( value = 0) Thank you very much for your response. Regards, Ferry ________________________________ From: Trent Jarvi To: Ferry Sumendap Cc: rxtx at qbang.org Sent: Tuesday, April 14, 2009 11:01:04 AM Subject: Re: [Rxtx] In Linux, RXTX serial port lib cannot send character which hex is more than 127. On Mon, 13 Apr 2009, Ferry Sumendap wrote: > Hello everybody, > > I have just tested the RXTXserial port library version RXTX2-1-7pre20 to > send two characters which are character ascii 230 and 234. It seems that > the driver somehow did not send the two characters into serial port if the > Operating System is Linux Mandriva 2007 (kernel version 2.6.17-13mdv > ) or Linux Mandriva 2009. > I also tried the driver using same java code (java class file of the > program I wrote), in Windows XP, it does work. > > Should I configure something (special configuration in Linux) or did I miss > something ? > I also have tested the latest RXTX 2.2pre2 driver, but it still have that > problem. > Hello Ferry This sounds like an unlikely problem. Even with USB dongle issues, I can't think of a reason that would be a problem. Is this a connection at 9600 8N1? Sometimes it really is the cable. -- Trent Jarvi tjarvi at qbang.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090413/27a37ea5/attachment-0005.html From ferry_new2004 at yahoo.com Mon Apr 13 22:23:53 2009 From: ferry_new2004 at yahoo.com (Ferry Sumendap) Date: Mon, 13 Apr 2009 21:23:53 -0700 (PDT) Subject: [Rxtx] In Linux, RXTX serial port lib cannot send character which hex is more than 127. In-Reply-To: References: <30875.39589.qm@web33106.mail.mud.yahoo.com> <81465.86461.qm@web33102.mail.mud.yahoo.com> Message-ID: <736778.48214.qm@web33108.mail.mud.yahoo.com> I am sorry not telling you about the configuration.. Yes I did test using the same serial port configuration, but the RXTX did not work properly. I also use "root" just in case there is security violation. If I sent another character that is below 127 (ascii < 127) the RXTX works properly either in LINUX or WINDOWS. I also cannot believe that coders of RXTX would make diffentiation between baudrate 19200 and 9600. The driver actually works very good unfortunately if the character is upper than ascii 127 (like ascii 230 and 234) it will not work. Thank you very much. Regards, Ferry ________________________________ From: Trent Jarvi To: Ferry Sumendap Cc: Trent Jarvi Sent: Tuesday, April 14, 2009 11:16:34 AM Subject: Re: [Rxtx] In Linux, RXTX serial port lib cannot send character which hex is more than 127. Hi Ferry, The only thing you mention that is not tested on a regular basis is the 19200 baudrate. There is nothing special (code wise) about that baudrate. On Mon, 13 Apr 2009, Ferry Sumendap wrote: > Thank you for your answer. > > I use the same machine, cable and devices to test. > My PC is installed with Linux Mandriva and WINDOWS. > The serial port physically have no problem since using Windows, it works. > > I also tested the serial port using MONI (tcl based program). > MONI is linux based program to send some characters to serial port. > Using MONI, I sent the characters to /dev/ttyS0, and it works because the > device which is plugged in /dev/ttyS0 received and answered the message. > > But for RXTX, some how, java based program cannot send those characters. > With the same java based program, it works properly in WINDOWS and the same > cable, devices, hardware specification. > That's why I am curious about RXTX. > > > > Here is the serial port configuration I used. > > Com Port /dev/ttyS0 > Baud rate 19200 > Data bits 8 ( value = 8) > Stop bits 1 ( value = 1) > Parity None ( value = 0) > > > > Thank you very much for your response. > > Regards, > Ferry > > > ____________________________________________________________________________ > From: Trent Jarvi > To: Ferry Sumendap > Cc: rxtx at qbang.org > Sent: Tuesday, April 14, 2009 11:01:04 AM > Subject: Re: [Rxtx] In Linux, RXTX serial port lib cannot send character > which hex is more than 127. > > > > On Mon, 13 Apr 2009, Ferry Sumendap wrote: > > > Hello everybody, > > > > I have just tested the RXTXserial port library version RXTX2-1-7pre20 to > > send two characters which are character ascii 230 and 234. It seems that > > the driver somehow did not send the two characters into serial port if the > > Operating System is Linux Mandriva 2007 (kernel version 2.6.17-13mdv > > ) or Linux Mandriva 2009. > > I also tried the driver using same java code (java class file of the > > program I wrote), in Windows XP, it does work. > > > > Should I configure something (special configuration in Linux) or did I > miss > > something ? > > I also have tested the latest RXTX 2.2pre2 driver, but it still have that > > problem. > > > > Hello Ferry > > This sounds like an unlikely problem. > > Even with USB dongle issues, I can't think of a reason that would be a > problem. Is this a connection at 9600 8N1? > > Sometimes it really is the cable. > > -- > Trent Jarvi > tjarvi at qbang.org > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090413/7a2fd5a0/attachment-0005.html From tjarvi at qbang.org Mon Apr 13 22:45:09 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 13 Apr 2009 22:45:09 -0600 (MDT) Subject: [Rxtx] In Linux, RXTX serial port lib cannot send character which hex is more than 127. In-Reply-To: <736778.48214.qm@web33108.mail.mud.yahoo.com> References: <30875.39589.qm@web33106.mail.mud.yahoo.com> <81465.86461.qm@web33102.mail.mud.yahoo.com> <736778.48214.qm@web33108.mail.mud.yahoo.com> Message-ID: This sounds like a signed vs unsigned char issue. Given that rxtx does binary read and write fine on Linux, I'm at a loss of what your problem may be. No, I don't suspect the baudrate is an issue either. On Mon, 13 Apr 2009, Ferry Sumendap wrote: > I am sorry not telling you about the configuration.. > > Yes I did test using the same serial port configuration, but the RXTX did > not work properly. > I also use "root" just in case there is security violation. > If? I sent another character that is below 127 (ascii < 127) the RXTX works > properly either in LINUX or WINDOWS. > > I also cannot believe that coders of RXTX would make diffentiation between > baudrate 19200 and 9600. > The driver actually works very good unfortunately if the character is upper > than ascii 127 (like ascii 230 and 234) it will not work. > > Thank you very much. > Regards, > > Ferry > > ____________________________________________________________________________ > From: Trent Jarvi > To: Ferry Sumendap > Cc: Trent Jarvi > Sent: Tuesday, April 14, 2009 11:16:34 AM > Subject: Re: [Rxtx] In Linux, RXTX serial port lib cannot send character > which hex is more than 127. > > > Hi Ferry, > > The only thing you mention that is not tested on a regular basis is the > 19200 baudrate.? There is nothing special (code wise) about that baudrate. > > On Mon, 13 Apr 2009, Ferry Sumendap wrote: > > > Thank you for your answer. > > > > I use the same machine, cable and devices to test. > > My PC is installed with Linux Mandriva and WINDOWS. > > The serial port physically have no problem since using Windows, it works. > > > > I also tested the serial port using MONI (tcl based program). > > MONI is linux based program to send some characters to serial port. > > Using MONI, I sent the characters to /dev/ttyS0, and it works because the > > device which is plugged in /dev/ttyS0 received and answered the message. > > > > But for RXTX, some how, java based program cannot send those characters. > > With the same java based program, it works properly in WINDOWS and the > same > > cable, devices, hardware specification. > > That's why I am curious about RXTX. > > > > > > > > Here is the serial port configuration I used. > > > > Com Port /dev/ttyS0 > > Baud rate 19200 > > Data bits 8 ( value = 8) > > Stop bits 1?? ( value = 1) > > Parity None? ( value = 0) > > > > > > > > Thank you very much for your response. > > > > Regards, > > Ferry > > > > > >___________________________________________________________________________ > _ > > From: Trent Jarvi > > To: Ferry Sumendap > > Cc: rxtx at qbang.org > > Sent: Tuesday, April 14, 2009 11:01:04 AM > > Subject: Re: [Rxtx] In Linux, RXTX serial port lib cannot send character > > which hex is more than 127. > > > > > > > > On Mon, 13 Apr 2009, Ferry Sumendap wrote: > > > > > Hello everybody, > > > > > > I have just tested the RXTXserial port library version? RXTX2-1-7pre20 > to > > > send two characters which are character ascii? 230 and 234. It seems > that > > > the driver somehow did not send the two characters into serial port if > the > > > Operating System is Linux Mandriva 2007 (kernel version 2.6.17-13mdv > > > ) or Linux Mandriva 2009. > > > I also tried the driver using? same java code (java class file of the > > > program I wrote), in Windows XP,? it does work. > > > > > > Should I configure something (special configuration in Linux)? or did I > > miss > > > something ? > > > I also have tested the latest RXTX 2.2pre2 driver, but it still have > that > > > problem. > > > > > > > Hello Ferry > > > > This sounds like an unlikely problem. > > > > Even with USB dongle issues, I can't think of a reason that would be a > > problem.? Is this a connection at 9600 8N1? > > > > Sometimes it really is the cable. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > > > > > > > > From ilkka at myller.com Mon Apr 13 23:12:16 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 14 Apr 2009 08:12:16 +0300 Subject: [Rxtx] In Linux, RXTX serial port lib cannot send character which hex is more than 127. In-Reply-To: References: <30875.39589.qm@web33106.mail.mud.yahoo.com> <81465.86461.qm@web33102.mail.mud.yahoo.com> <736778.48214.qm@web33108.mail.mud.yahoo.com> Message-ID: Hi, Another suggestion: incorrect java byte casting. Java byte type has a range from -128 to 127. I've seen people assume range of 0 - 255. Incorrect integer casting with bytes is a common mistake is to cause those >127 ascii issues. Could it be? (int)b versus (int)(b & 0xFF) -- I Trent Jarvi kirjoitti 14.4.2009 kello 7.45: > > This sounds like a signed vs unsigned char issue. Given that rxtx > does binary read and write fine on Linux, I'm at a loss of what your > problem may be. > > No, I don't suspect the baudrate is an issue either. > > On Mon, 13 Apr 2009, Ferry Sumendap wrote: > >> I am sorry not telling you about the configuration.. >> Yes I did test using the same serial port configuration, but the >> RXTX did >> not work properly. >> I also use "root" just in case there is security violation. >> If I sent another character that is below 127 (ascii < 127) the >> RXTX works >> properly either in LINUX or WINDOWS. >> I also cannot believe that coders of RXTX would make diffentiation >> between >> baudrate 19200 and 9600. >> The driver actually works very good unfortunately if the character >> is upper >> than ascii 127 (like ascii 230 and 234) it will not work. >> Thank you very much. >> Regards, >> Ferry >> ____________________________________________________________________________ >> From: Trent Jarvi >> To: Ferry Sumendap >> Cc: Trent Jarvi >> Sent: Tuesday, April 14, 2009 11:16:34 AM >> Subject: Re: [Rxtx] In Linux, RXTX serial port lib cannot send >> character >> which hex is more than 127. >> Hi Ferry, >> The only thing you mention that is not tested on a regular basis is >> the >> 19200 baudrate. There is nothing special (code wise) about that >> baudrate. >> On Mon, 13 Apr 2009, Ferry Sumendap wrote: >> > Thank you for your answer. >> > >> > I use the same machine, cable and devices to test. >> > My PC is installed with Linux Mandriva and WINDOWS. >> > The serial port physically have no problem since using Windows, >> it works. >> > >> > I also tested the serial port using MONI (tcl based program). >> > MONI is linux based program to send some characters to serial port. >> > Using MONI, I sent the characters to /dev/ttyS0, and it works >> because the >> > device which is plugged in /dev/ttyS0 received and answered the >> message. >> > >> > But for RXTX, some how, java based program cannot send those >> characters. >> > With the same java based program, it works properly in WINDOWS >> and the >> same >> > cable, devices, hardware specification. >> > That's why I am curious about RXTX. >> > >> > >> > >> > Here is the serial port configuration I used. >> > >> > Com Port /dev/ttyS0 >> > Baud rate 19200 >> > Data bits 8 ( value = 8) >> > Stop bits 1 ( value = 1) >> > Parity None ( value = 0) >> > >> > >> > >> > Thank you very much for your response. >> > >> > Regards, >> > Ferry >> > >> > >> > >> ___________________________________________________________________________ >> _ >> > From: Trent Jarvi >> > To: Ferry Sumendap >> > Cc: rxtx at qbang.org >> > Sent: Tuesday, April 14, 2009 11:01:04 AM >> > Subject: Re: [Rxtx] In Linux, RXTX serial port lib cannot send >> character >> > which hex is more than 127. >> > >> > >> > >> > On Mon, 13 Apr 2009, Ferry Sumendap wrote: >> > >> > > Hello everybody, >> > > >> > > I have just tested the RXTXserial port library version >> RXTX2-1-7pre20 >> to >> > > send two characters which are character ascii 230 and 234. It >> seems >> that >> > > the driver somehow did not send the two characters into serial >> port if >> the >> > > Operating System is Linux Mandriva 2007 (kernel version >> 2.6.17-13mdv >> > > ) or Linux Mandriva 2009. >> > > I also tried the driver using same java code (java class file >> of the >> > > program I wrote), in Windows XP, it does work. >> > > >> > > Should I configure something (special configuration in Linux) >> or did I >> > miss >> > > something ? >> > > I also have tested the latest RXTX 2.2pre2 driver, but it still >> have >> that >> > > problem. >> > > >> > >> > Hello Ferry >> > >> > This sounds like an unlikely problem. >> > >> > Even with USB dongle issues, I can't think of a reason that would >> be a >> > problem. Is this a connection at 9600 8N1? >> > >> > Sometimes it really is the cable. >> > >> > -- >> > Trent Jarvi >> > tjarvi at qbang.org >> > >> > >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From sunil at saltriver.com Tue Apr 14 01:06:38 2009 From: sunil at saltriver.com (Sunil Bhambani) Date: Tue, 14 Apr 2009 07:06:38 -0000 Subject: [Rxtx] RxTx on Mac for USB Message-ID: <1080422816.3127.6.camel@localhost.localdomain> Hi, I have a GPS device which is USB device. I want to use that device on Mac System and Java as the programming language. I have read that USB support through RxTx on Mac is not there. Is this correct? I would like to read the data that comes to GPS device. Can some connector be used to communicate with that device. For example USB to RJ11 or USB to serial connector? Are this connectors reliable enough to be used? Hope to get the reply soon. -- Thank & Regards Sunil -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090414/295ccb1d/attachment-0004.html From helgeingvart at gmail.com Tue Apr 14 01:43:04 2009 From: helgeingvart at gmail.com (Helge Fredriksen) Date: Tue, 14 Apr 2009 09:43:04 +0200 Subject: [Rxtx] IO exceptions on 2.2pre2 In-Reply-To: References: <306B677E-9207-44CB-81CD-787A50DB7DA6@myller.com> Message-ID: FYI: There seem to be success on this problem by switching to your commercial counterpart from SerialIO (http://www.serialio.com). A FTDI only problem? Best regards, Helge Fredriksen On Sat, Mar 28, 2009 at 5:32 PM, Helge Fredriksen wrote: > Thanks for your suggestions, > > We have tried switching off the power saving settings as recommended, but > regrettably we see the same things happening still. > > The FTDI device is not connected directly to USB hubs, no. > > Someone have any more ideas? > > Best regards, > Helge Fredriksen > > > On Tue, Mar 24, 2009 at 9:27 AM, Ilkka Myller wrote: > >> Hi Helge, >> >> I am not sure if this will help, but you could try this: >> >> echo on > /sys/bus/usb/devices//power/level >> echo 0 > /sys/bus/usb/devices//power/autosuspend >> >> is the USB-bus device id of your FTDI adapter (bus-device, for >> example "2-2") >> >> This will disable USB power saving/autosuspend of FTDI USB-device. >> I've seen some some systems where this helps with FTDI-adapter connection >> drops. >> >> Also: is your FTDI device directly connected to PC's USB root hub? If not, >> test that too. >> >> >> -- >> I >> >> (replace with the usb bus device id of your FTDI serial >> adapter) >> >> Helge Fredriksen kirjoitti 24.3.2009 kello 9.45: >> >> Hello! >> >> Here's the device details: >> >> FT232R is a USB to serial UART interface. >> >> Link to componentt: http://www.ftdichip.com/Products/FT232R.htm >> >> Regards, >> Helge Fredriksen >> >> On Tue, Mar 24, 2009 at 12:05 AM, Trent Jarvi wrote: >> >>> >>> >>> On Mon, 23 Mar 2009, Helge Fredriksen wrote: >>> >>> Hello again. >>>> >>>> I'm having a bit trouble with the 2.2pre2 version it seems. I'm having >>>> an >>>> application running on Ubuntu 8.10 that seem to run stable but after an >>>> hour >>>> or so the application breaks down with lot's of IO exceptions like this: >>>> >>>> java.io.IOException: Input/output error in nativeavailable >>>> at gnu.io.RXTXPort.nativeavailable(Native Method) >>>> at gnu.io.RXTXPort$SerialInputStream.available(RXTXPort.java:1596) >>>> >>>> atcom.poseidon.usb.UsbInterface$MySerialPortEventListener.serialEvent(UsbInte >>>> rface.java:251) >>>> at gnu.io.RXTXPort.sendEvent(RXTXPort.java:772) >>>> at gnu.io.RXTXPort.eventLoop(Native Method) >>>> at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1641) >>>> >>>> Any ideas? >>>> >>> >>> Hi Helge, >>> >>> It sounds like the file descriptor (USB driver) is in an invalid state. >>> >>> What can you tell us about the USB dongle? Is it bluetooth? Do you know >>> what chipset is in it? >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090414/e2c97c4f/attachment-0005.html From Steffen.DETTMER at ingenico.com Tue Apr 14 02:21:35 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 14 Apr 2009 10:21:35 +0200 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49E3F7D0.5090207@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49E3B6E3.5050203@cox.net> <49E3F7D0.5090207@bbs.darktech.org> Message-ID: <20090414082135.GG5090@elberon.bln.de.ingenico.com> * cowwoc wrote on Mon, Apr 13, 2009 at 22:41 -0400: > Gregg Wonderly wrote: > > The real issue is that you have to understand that > > the on the Sun JVM, the GC can run finalization or advertise a dropped > > reference before an object is actually unreferenced in some cases. > > I've never seen this myself. Can you reproduce it on the latest JRE? If > so, this sounds like a bug to me and should be fixed. Please consider > filing a bug report and telling me the bug number. I'll try running it > by my Sun contacts. I found some general hints here: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2261.html Traditional finalization in garbage collected languages is defined in terms of object reachability. But objects can easily become "unreachable" earlier than the programmer expects, due to compiler optimizations. An object may be logically in use long past the last point at which the memory associated with the object is accessed or referenced by any pointers visible to the garbage collector. In the worst case, the compiler might decide to store all the fields of an object in registers, and then observe that the "this" pointer for the newly allocated memory is dead immediately after the allocation, and hence not save it anywhere. The garbage collector, even if run immediately after the allocation, would then discover that the memory object is no longer reachable, and run the finalizer immediately, in spite of the fact that the object fields are still in use, and in fact may remain in use after the finalizer has run. However, if this would be a so general weakness that someone is adviced to store object instances in collections instead of using members or having the references on the stack - even if used correctly - I think it would be a major weakness which probably had been fixed, because otherwise raping collections as such workarounds would be commonly visible. BTW, I think the citation above is wrong if the optimised member values are used after that. The destructor / finalizer may set all fields to null or so and (ordinary) optimizers should not affect the behavior of correct and usual code I think. (ohh, and Cowwoc, forced-GC and to forbid the developer to control lifecycle in Java is considered a feature, not a bug! -- SCNR) oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From michael.erskine at ketech.com Tue Apr 14 02:50:53 2009 From: michael.erskine at ketech.com (Michael Erskine) Date: Tue, 14 Apr 2009 09:50:53 +0100 Subject: [Rxtx] Wiki Spam pages - need of captcha? In-Reply-To: References: Message-ID: <06BA3262D918014F9183B66425D5A8D45FA42D88FB@no-sv-03.ketech.local> All, See http://tech.slashdot.org/article.pl?sid=09/04/13/0120226 for details of this particular use of open wiki sites and the apology. Regards, Michael Erskine. From Steffen.DETTMER at ingenico.com Tue Apr 14 04:27:53 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 14 Apr 2009 12:27:53 +0200 Subject: [Rxtx] In Linux, RXTX serial port lib cannot send character which hex is more than 127. In-Reply-To: <30875.39589.qm@web33106.mail.mud.yahoo.com> References: <30875.39589.qm@web33106.mail.mud.yahoo.com> Message-ID: <20090414102753.GI5090@elberon.bln.de.ingenico.com> * Ferry Sumendap wrote on Mon, Apr 13, 2009 at 20:24 -0700: > I have just tested the RXTXserial port library version > RXTX2-1-7pre20 to send two characters which are character ascii > 230 and 234. Can you send -26 and -22 instead? Then it probably is a casting issue (as Trent and Ilkka already considered). oki, Steffen End of message. ------------------------------------------------------------------->8======= About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Bob_Jacobsen at lbl.gov Tue Apr 14 08:31:13 2009 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Tue, 14 Apr 2009 07:31:13 -0700 Subject: [Rxtx] RxTx on Mac for USB In-Reply-To: <1080422816.3127.6.camel@localhost.localdomain> References: <1080422816.3127.6.camel@localhost.localdomain> Message-ID: At 2:56 AM +0530 3/28/04, Sunil Bhambani wrote: >Hi, > >I have a GPS device which is USB device. I want to use that device >on Mac System and Java as the programming language. I have read that >USB support through RxTx on Mac is not there. Is this correct? I >would like to read the data that comes to GPS device. Can some >connector be used to communicate with that device. For example USB >to RJ11 or USB to serial connector? Are this connectors reliable >enough to be used? If the GPS device looks like a serial device to Mac OS X (Darwin), RXTX will work fine. To check: *) Unplug your device. *) Do the following command line, and keep the output: ls -lt /dev/ | head -10 *) Plug in your device and wait a couple seconds *) Repeat the above command line, and see if there are any new entries at the top of the output. The new entries, if any, are how your GPS device was mounted. If the new device(s) start with /dev/tty or /dev/cu, you'll be able to use RXTX. As a next step, you can use the "cu" command to try to talk to your GPS device as serial device. For example, cu -s 19200 -l /dev/tty.usbserial-LWPMMU13 You can download RXTX installers for various MacOS X version from here: But note these are for RXTX 2.0 versions (javax.comm package). Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From sunil at saltriver.com Wed Apr 15 00:06:40 2009 From: sunil at saltriver.com (Sunil Bhambani) Date: Wed, 15 Apr 2009 06:06:40 -0000 Subject: [Rxtx] RxTx on Mac for USB In-Reply-To: References: <1080422816.3127.6.camel@localhost.localdomain> Message-ID: <1080505612.2924.9.camel@localhost.localdomain> On Tue, 2009-04-14 at 07:31 -0700, Bob Jacobsen wrote: > At 2:56 AM +0530 3/28/04, Sunil Bhambani wrote: > >Hi, > > > >I have a GPS device which is USB device. I want to use that device > >on Mac System and Java as the programming language. I have read that > >USB support through RxTx on Mac is not there. Is this correct? I > >would like to read the data that comes to GPS device. Can some > >connector be used to communicate with that device. For example USB > >to RJ11 or USB to serial connector? Are this connectors reliable > >enough to be used? > > If the GPS device looks like a serial device to Mac OS X (Darwin), > RXTX will work fine. > > To check: > > *) Unplug your device. > *) Do the following command line, and keep the output: > > ls -lt /dev/ | head -10 > > *) Plug in your device and wait a couple seconds > > *) Repeat the above command line, and see if there are any new > entries at the top of the output. > > The new entries, if any, are how your GPS device was mounted. If the > new device(s) start with /dev/tty or /dev/cu, you'll be able to use > RXTX. > > As a next step, you can use the "cu" command to try to talk to your > GPS device as serial device. For example, > > cu -s 19200 -l /dev/tty.usbserial-LWPMMU13 > > You can download RXTX installers for various MacOS X version from here: > > > > But note these are for RXTX 2.0 versions (javax.comm package). > > Bob Hi Bob, I am using Mac 10.5 and I have done what you have said. I get the following output total 4 crw--w---- 1 Saltriver tty 16, 0 Apr 15 11:13 ttys000 crw-rw-rw- 1 root wheel 8, 0 Apr 15 11:13 random crw-rw-rw- 1 root tty 15, 1 Apr 15 11:13 ptmx crw------- 1 Saltriver staff 0, 0 Apr 15 11:10 console crw-rw-rw- 1 root wheel 3, 2 Apr 15 10:58 null crw------- 1 root wheel 23, 1 Apr 15 10:32 bpf1 crw------- 1 root wheel 23, 0 Apr 15 10:32 bpf0 crw------- 1 root wheel 11, 0 Apr 15 10:31 autofs crw------- 1 root wheel 17, 0 Apr 15 10:31 autofs_control saltriver-infosystemss-mac-mini:~ Saltriver$ ls -lt /dev/ | head -10 total 4 crw--w---- 1 Saltriver tty 16, 0 Apr 15 11:16 ttys000 crw-rw-rw- 1 root tty 15, 1 Apr 15 11:16 ptmx crw-rw-rw- 1 root wheel 8, 0 Apr 15 11:13 random crw------- 1 Saltriver staff 0, 0 Apr 15 11:10 console crw-rw-rw- 1 root wheel 3, 2 Apr 15 10:58 null crw------- 1 root wheel 23, 1 Apr 15 10:32 bpf1 crw------- 1 root wheel 23, 0 Apr 15 10:32 bpf0 crw------- 1 root wheel 11, 0 Apr 15 10:31 autofs crw------- 1 root wheel 17, 0 Apr 15 10:31 autofs_control I think the output is same in both. Is there any way of mounting that device. I am very new to Mac. I am using RXTX 2.1 without javax.comm package. I have tried the same code in fedora and it ran successfully. I have tried inserting pen drive in the USB port and it was detected. Hope to get a quick reply from you. Thanks & Regards Sunil -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090415/19e599e5/attachment-0003.html From Bob_Jacobsen at lbl.gov Wed Apr 15 03:43:26 2009 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Wed, 15 Apr 2009 02:43:26 -0700 Subject: [Rxtx] RxTx on Mac for USB In-Reply-To: <1080505612.2924.9.camel@localhost.localdomain> References: <1080422816.3127.6.camel@localhost.localdomain> <1080505612.2924.9.camel@localhost.localdomain> Message-ID: At 1:56 AM +0530 3/29/04, Sunil Bhambani wrote: > >I am using Mac 10.5 and I have done what you have said. I get the >following output > >total 4 >crw--w---- 1 Saltriver tty 16, 0 Apr 15 11:13 ttys000 >crw-rw-rw- 1 root wheel 8, 0 Apr 15 11:13 random >crw-rw-rw- 1 root tty 15, 1 Apr 15 11:13 ptmx >crw------- 1 Saltriver staff 0, 0 Apr 15 11:10 console ... >saltriver-infosystemss-mac-mini:~ Saltriver$ ls -lt /dev/ | head -10 >total 4 >crw--w---- 1 Saltriver tty 16, 0 Apr 15 11:16 ttys000 >crw-rw-rw- 1 root tty 15, 1 Apr 15 11:16 ptmx >crw-rw-rw- 1 root wheel 8, 0 Apr 15 11:13 random >crw------- 1 Saltriver staff 0, 0 Apr 15 11:10 console ... >I think the output is same in both. Is there any way of mounting that device. You're going to need a driver of some sort that will make the GPS unit appear as a serial device. > I am very new to Mac. I am using RXTX 2.1 without javax.comm package. This problem is happening before RXTX can do anything at all. Unless there's a device in /dev, RXTX can't even begin to be involved. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From cowwoc at bbs.darktech.org Wed Apr 15 09:08:21 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Wed, 15 Apr 2009 11:08:21 -0400 Subject: [Rxtx] RxTX mentioned on Sun's Java Communications page In-Reply-To: References: Message-ID: <49E5F865.1030206@bbs.darktech.org> >> Looks like RxTx really is the closest thing we have to the 'official' >> implementation. > > Ugh. I don't know of any developer interest in maintaining rxtx 2.0. It > would be cleaner for Sun to just openly take javax.comm for their Sun Ray > project. > > If someone is interested in maintaining rxtx 2.0, don't be afraid to say > so. Just curious, why not have the javax.comm layer just call gnu.io under the hood? This will make require no real work to maintain it even if the underlying implementation keeps on changing. From what I've seen so far the difference between the two APIs is minimal in most places. Gili From Kustaa.Nyholm at planmeca.com Wed Apr 15 09:42:33 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 15 Apr 2009 18:42:33 +0300 Subject: [Rxtx] Java5 support In-Reply-To: <49D7CD82.1040904@bbs.darktech.org> Message-ID: A recent post reminded me of this old thread that I do not think got any replies. Here is my take on the subject (of improving the API): Please do not 'improve' the API! Serial port is an old, simple and mature thing. Let's keep it that way. Very little will be gained by 'improving' it. It is already too bad that Sun spoiled the internals of javax.comm in version 3,0 so that the gnu.io package had to be coined. That is a nuisance but nothing compared to what happens if we start 'improve' the API and make it incompatible with Java Comm API. Even additions should be resisted as this will encourage people to write code that is not compatible with the 'standard' Java Comm API. The world does not need more standards but better compliance to existing standards. If someone feels things like generics/iterators for are needed it is simple to wrap the rxtx or java comm classes into classes to implement these new language features without changing the API. rxtx us great and many thanks and cudos to the maintainers and creators but it is lamentable that something this basic needs to be addressed outside standard JRE. Not to mention being able to do basic USB stuff in Java/std JRE in cross platform deployable fashion. br Kusti > From: cowwoc > Date: Sun, 5 Apr 2009 00:13:38 +0300 > To: > Conversation: [Rxtx] Java5 support > Subject: [Rxtx] Java5 support > > > > Now that you dropped javax.comm support, how about improving the API > by replacing Enumation by Iterator, int by enum, and using Generics? It > would improve the usability of the API. > > Gili > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From cowwoc at bbs.darktech.org Wed Apr 15 11:35:03 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Wed, 15 Apr 2009 13:35:03 -0400 Subject: [Rxtx] YACK Message-ID: <49E61AC7.2060701@bbs.darktech.org> Hi, Please increase the YACK() buffer size from 80 characters to 160. My long paths lead to the following kinds of errors: Error 0x5 at c:\users\gili\documents\rxtx\rxtx-devel\src\termios.c(892): AccessError 0x5 at c:\users\gili\documents\rxtx\rxtx-devel\src\termios.c(892): Access Thanks, Gili From talberts at msiscales.com Wed Apr 15 12:22:20 2009 From: talberts at msiscales.com (Tim Alberts) Date: Wed, 15 Apr 2009 11:22:20 -0700 Subject: [Rxtx] RxTX mentioned on Sun's Java Communications page In-Reply-To: <49E5F865.1030206@bbs.darktech.org> References: <49E5F865.1030206@bbs.darktech.org> Message-ID: <49E625DC.80509@msiscales.com> cowwoc wrote: >>> Looks like RxTx really is the closest thing we have to the 'official' >>> implementation. >>> >> Ugh. I don't know of any developer interest in maintaining rxtx 2.0. It >> would be cleaner for Sun to just openly take javax.comm for their Sun Ray >> project. >> >> If someone is interested in maintaining rxtx 2.0, don't be afraid to say >> so. >> > > Just curious, why not have the javax.comm layer just call gnu.io under > the hood? This will make require no real work to maintain it even if the > underlying implementation keeps on changing. From what I've seen so far > the difference between the two APIs is minimal in most places. > > Gili I can't help but get in on this discussion thread. I starting using javax.comm from Sun and I've got a huge project that is entirely based on it now. Sun dropped support for windows which is a huge disappointment for me. I read Sun's page that if you want serial ports on Java with Windows, go to RXTX. I did this. In my experiments I've found by trial and error (and by discussion on this list) that under the hood, Sun javax.comm and RXTX gnu.io are completely different. So since Sun doesn't care about anyone who doesn't use their platforms (or at least anyone that uses Windows). I would argue that RXTX has no obligation to Sun. On another note, I have yet to see (or get) RXTX to work in my code that works perfectly fine using the old Sun javax.comm for windows binaries that I am forced to continue to run on. -------------- next part -------------- A non-text attachment was scrubbed... Name: talberts.vcf Type: text/x-vcard Size: 337 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20090415/a373e7f2/attachment-0003.vcf From cowwoc at bbs.darktech.org Wed Apr 15 13:13:03 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Wed, 15 Apr 2009 15:13:03 -0400 Subject: [Rxtx] Java5 support In-Reply-To: References: Message-ID: <49E631BF.9040501@bbs.darktech.org> > > A recent post reminded me of this old thread that I do not think got any > replies. > > Here is my take on the subject (of improving the API): > > Please do not 'improve' the API! > > Serial port is an old, simple and mature thing. Let's keep it that way. > Very little will be gained by 'improving' it. It is already too bad > that Sun spoiled the internals of javax.comm in version 3,0 so that the > gnu.io package had to be coined. That is a nuisance but nothing compared to > what happens if we start 'improve' the API and make it incompatible with > Java Comm API. > > Even additions should be resisted as this will encourage people to write > code that is not compatible with the 'standard' Java Comm API. The world > does not need more standards but better compliance to existing standards. > > If someone feels things like generics/iterators for are needed it is simple > to wrap the rxtx or java comm classes into classes to implement these > new language features without changing the API. > > rxtx us great and many thanks and cudos to the maintainers and creators but > it is lamentable that something this basic needs to be addressed outside > standard JRE. Not to mention being able to do basic USB stuff in Java/std > JRE in cross platform deployable fashion. > > br Kusti Hi Kusti, I must be missing something... I thought the entire point of forking off gnu.io was to innovate the API in a different direction than javax.comm, otherwise why wouldn't you stick to the standard API? Thanks, Gili From cowwoc at bbs.darktech.org Wed Apr 15 14:57:46 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Wed, 15 Apr 2009 16:57:46 -0400 Subject: [Rxtx] Timeout patch Message-ID: <49E64A4A.1050806@bbs.darktech.org> Hi, Please review the attached patch. - fixes disableReceiveTimeout() so reads now block until data is available. - receive timeouts and threshold handling is now more consistent across all implementations Gili -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: timeout.patch Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20090415/6815e522/attachment-0003.pl From bschlining at gmail.com Wed Apr 15 17:15:10 2009 From: bschlining at gmail.com (Brian Schlining) Date: Wed, 15 Apr 2009 16:15:10 -0700 Subject: [Rxtx] Timeout patch In-Reply-To: <49E64A4A.1050806@bbs.darktech.org> References: <49E64A4A.1050806@bbs.darktech.org> Message-ID: > > - fixes disableReceiveTimeout() so reads now block until data is available. Finally!! Thanks for submitting this patch. Hopefully it'll be integrated soon. Cheers -- B ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090415/a4143da7/attachment-0003.html From tristan.dyer at cgi.com Wed Apr 15 17:32:43 2009 From: tristan.dyer at cgi.com (Dyer, Tristan) Date: Wed, 15 Apr 2009 19:32:43 -0400 Subject: [Rxtx] Java5 support In-Reply-To: <49E631BF.9040501@bbs.darktech.org> References: <49E631BF.9040501@bbs.darktech.org> Message-ID: <9DA32B4D8579AF44AD96C1CC2E9C518D0346E9EB@MTL-MSG-02.cgiclients.com> That's weird. All I had to do to get my project running on RxTx was to change javax.comm to gnu.io I assume the reason for the fork to gnu.io was precisely to preserve compatibility with javax.comm. Unless Sun is willing to give you a TCK (or someone wants to pay for it) you wouldn't be able to provide any of the "new" javax.comm 3.0 feature set to windows and call it javax.comm, and as a side effect you get to keep the api consistent across platforms as well. Apache has been in a pissing fight with Sun for a couple years about this in regards to Harmony. As I remember rxtx was a lower level that suns CommAPI jar could talk to, to provide javax.comm on linux originally. With sun only providing CommAPI for some environments it became necessary to fork. At least that's how I assume it got here. Tristan -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of cowwoc Sent: Wednesday, April 15, 2009 4:13 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Java5 support > > A recent post reminded me of this old thread that I do not think got any > replies. > > Here is my take on the subject (of improving the API): > > Please do not 'improve' the API! > > Serial port is an old, simple and mature thing. Let's keep it that way. > Very little will be gained by 'improving' it. It is already too bad > that Sun spoiled the internals of javax.comm in version 3,0 so that the > gnu.io package had to be coined. That is a nuisance but nothing compared to > what happens if we start 'improve' the API and make it incompatible with > Java Comm API. > > Even additions should be resisted as this will encourage people to write > code that is not compatible with the 'standard' Java Comm API. The world > does not need more standards but better compliance to existing standards. > > If someone feels things like generics/iterators for are needed it is simple > to wrap the rxtx or java comm classes into classes to implement these > new language features without changing the API. > > rxtx us great and many thanks and cudos to the maintainers and creators but > it is lamentable that something this basic needs to be addressed outside > standard JRE. Not to mention being able to do basic USB stuff in Java/std > JRE in cross platform deployable fashion. > > br Kusti Hi Kusti, I must be missing something... I thought the entire point of forking off gnu.io was to innovate the API in a different direction than javax.comm, otherwise why wouldn't you stick to the standard API? Thanks, Gili _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Apr 15 17:48:20 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 15 Apr 2009 17:48:20 -0600 (MDT) Subject: [Rxtx] Timeout patch In-Reply-To: <49E64A4A.1050806@bbs.darktech.org> References: <49E64A4A.1050806@bbs.darktech.org> Message-ID: On Wed, 15 Apr 2009, cowwoc wrote: > Hi, > > Please review the attached patch. > > - fixes disableReceiveTimeout() so reads now block until data is available. > - receive timeouts and threshold handling is now more consistent across all > implementations > Hi Gili, This looks good to me. One 'minor' issue is that you are returning -1 instead of 0 now on timeout. It is fair to say timeouts are the same as the end of input but that is new behavior in rxtx we should warn existing users about so they can adjust their code. -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Wed Apr 15 17:52:46 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Wed, 15 Apr 2009 19:52:46 -0400 Subject: [Rxtx] Timeout patch In-Reply-To: References: <49E64A4A.1050806@bbs.darktech.org> Message-ID: <49E6734E.4010809@bbs.darktech.org> Actually returning -1 on timeout would be bug on my part. I believe that InputStream is expecting us to return 0 in such a case. Which part of my patch changes the return value? Thanks, Gili Trent Jarvi wrote: > On Wed, 15 Apr 2009, cowwoc wrote: > >> Hi, >> >> Please review the attached patch. >> >> - fixes disableReceiveTimeout() so reads now block until data is >> available. >> - receive timeouts and threshold handling is now more consistent >> across all implementations >> > > Hi Gili, > > This looks good to me. One 'minor' issue is that you are returning -1 > instead of 0 now on timeout. It is fair to say timeouts are the same as > the end of input but that is new behavior in rxtx we should warn > existing users about so they can adjust their code. > > -- > Trent Jarvi > tjarvi at qbang.org > From tjarvi at qbang.org Wed Apr 15 18:38:01 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 15 Apr 2009 18:38:01 -0600 (MDT) Subject: [Rxtx] Java5 support In-Reply-To: <9DA32B4D8579AF44AD96C1CC2E9C518D0346E9EB@MTL-MSG-02.cgiclients.com> References: <49E631BF.9040501@bbs.darktech.org> <9DA32B4D8579AF44AD96C1CC2E9C518D0346E9EB@MTL-MSG-02.cgiclients.com> Message-ID: The project isn't interested in breaking projects or changing the API. That said, we do allow some extensions to be added that are clearly marked as such. These extensions are all in the weird science category - they are not alternatives to doing what the API can already do or even something many people would want to use some of the time. The gnu.io namespace is used to avoid polluting of the javax.comm namespace. There are a number of reasons why we could be concerned about using javax.comm including political and/or legal questions but the main reason is a project like rxtx should do no harm. On Wed, 15 Apr 2009, Dyer, Tristan wrote: > That's weird. > > All I had to do to get my project running on RxTx was to change > javax.comm to gnu.io > > I assume the reason for the fork to gnu.io was precisely to preserve > compatibility with javax.comm. Unless Sun is willing to give you a TCK > (or someone wants to pay for it) you wouldn't be able to provide any of > the "new" javax.comm 3.0 feature set to windows and call it javax.comm, > and as a side effect you get to keep the api consistent across platforms > as well. Apache has been in a pissing fight with Sun for a couple years > about this in regards to Harmony. > > As I remember rxtx was a lower level that suns CommAPI jar could talk > to, to provide javax.comm on linux originally. With sun only providing > CommAPI for some environments it became necessary to fork. > > At least that's how I assume it got here. > > Tristan > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > Of cowwoc > Sent: Wednesday, April 15, 2009 4:13 PM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Java5 support > >> >> A recent post reminded me of this old thread that I do not think got > any >> replies. >> >> Here is my take on the subject (of improving the API): >> >> Please do not 'improve' the API! >> >> Serial port is an old, simple and mature thing. Let's keep it that > way. >> Very little will be gained by 'improving' it. It is already too bad >> that Sun spoiled the internals of javax.comm in version 3,0 so that > the >> gnu.io package had to be coined. That is a nuisance but nothing > compared to >> what happens if we start 'improve' the API and make it incompatible > with >> Java Comm API. >> >> Even additions should be resisted as this will encourage people to > write >> code that is not compatible with the 'standard' Java Comm API. The > world >> does not need more standards but better compliance to existing > standards. >> >> If someone feels things like generics/iterators for are needed it is > simple >> to wrap the rxtx or java comm classes into classes to implement these >> new language features without changing the API. >> >> rxtx us great and many thanks and cudos to the maintainers and > creators but >> it is lamentable that something this basic needs to be addressed > outside >> standard JRE. Not to mention being able to do basic USB stuff in > Java/std >> JRE in cross platform deployable fashion. >> >> br Kusti > > Hi Kusti, > > I must be missing something... I thought the entire point of forking > > off gnu.io was to innovate the API in a different direction than > javax.comm, otherwise why wouldn't you stick to the standard API? > > Thanks, > Gili > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Wed Apr 15 18:53:42 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 15 Apr 2009 18:53:42 -0600 (MDT) Subject: [Rxtx] Timeout patch In-Reply-To: <49E6734E.4010809@bbs.darktech.org> References: <49E64A4A.1050806@bbs.darktech.org> <49E6734E.4010809@bbs.darktech.org> Message-ID: Hi Gili, I guess the documentation just needs to be clear and consistant (which it really wasn't before). This is what caught my eye but looking above it, I see the previous documentation mentions -1 in places too. -*timeout threshold Behavior -*------------------------------------------------------------------------ -*0 0 blocks until 1 byte is available -*>0 0 blocks until timeout occurs, returns 0 on timeout -*>0 >0 blocks until timeout or reads threshold bytes, - returns 0 on timeout -*0 >0 blocks until reads threshold bytes - */ + * timeout threshold Behavior + * --------------------------------------------------------------------------- + * < 0 <= 0 blocks until any data is available. + * < 0 > 0 blocks until {@code min(threshold, b.len)} bytes are available. + * >=0 <=0 blocks for {@code timeout} ms or until any data is available. Returns -1 on timeout. + * >=0 > 0 blocks for {@code timeout} ms or until {@code min(threshold, b.len)} bytes are available. Returns -1 on timeout. On Wed, 15 Apr 2009, cowwoc wrote: > > Actually returning -1 on timeout would be bug on my part. I believe > that InputStream is expecting us to return 0 in such a case. Which part of my > patch changes the return value? > > Thanks, > Gili > > Trent Jarvi wrote: >> On Wed, 15 Apr 2009, cowwoc wrote: >> >>> Hi, >>> >>> Please review the attached patch. >>> >>> - fixes disableReceiveTimeout() so reads now block until data is >>> available. >>> - receive timeouts and threshold handling is now more consistent across >>> all implementations >>> >> >> Hi Gili, >> >> This looks good to me. One 'minor' issue is that you are returning -1 >> instead of 0 now on timeout. It is fair to say timeouts are the same as >> the end of input but that is new behavior in rxtx we should warn existing >> users about so they can adjust their code. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> > From cowwoc at bbs.darktech.org Wed Apr 15 19:26:28 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Wed, 15 Apr 2009 21:26:28 -0400 Subject: [Rxtx] Timeout patch In-Reply-To: References: <49E64A4A.1050806@bbs.darktech.org> <49E6734E.4010809@bbs.darktech.org> Message-ID: <49E68944.3050808@bbs.darktech.org> Hi Trent, Please modify the Javadoc to read that timeouts will return 0. PS: The rxtx source contains plenty of ... questionable ... lines of code. The following items come to mind: 1) In serial_read() we return -1 on various error codes instead of throwing the appropriate exception back into the Java layer. 2) Some Java methods print error messages to stdout instead of throwing exceptions on invalid input. 3) #ifdef LIFE_IS_GOOD (is this ever used?) and "/* Baby did a bad baad thing */". Ifdef and comments like this litter the code. 4) Most files use C-language instead of C++. I am not advocating fancy C++ but rather C code wrapped in objects. Moving variable declarations closer to their usage and perhaps grouping related methods into cohesive classes would improve readability. I know this is an open-source project, but the quality of the code freaks me out :) Is there any resistance to fixing some of these problems? Gili Trent Jarvi wrote: > > Hi Gili, > > I guess the documentation just needs to be clear and consistant (which > it really wasn't before). This is what caught my eye but looking > above it, I see the previous documentation mentions -1 in places too. > > -*timeout threshold Behavior > -*------------------------------------------------------------------------ > > -*0 0 blocks until 1 byte is available > -*>0 0 blocks until timeout occurs, returns 0 on timeout > -*>0 >0 blocks until timeout or reads threshold bytes, > - returns 0 on timeout > -*0 >0 blocks until reads threshold bytes > - */ > + * timeout threshold Behavior > + * > --------------------------------------------------------------------------- > > + * < 0 <= 0 blocks until any data is available. > + * < 0 > 0 blocks until {@code min(threshold, > b.len)} bytes are available. > + * >=0 <=0 blocks for {@code timeout} ms or until > any data is available. Returns -1 on timeout. > + * >=0 > 0 blocks for {@code timeout} ms or until > {@code min(threshold, b.len)} bytes are available. Returns -1 on timeout. > > > > On Wed, 15 Apr 2009, cowwoc wrote: > >> >> Actually returning -1 on timeout would be bug on my part. I >> believe that InputStream is expecting us to return 0 in such a case. >> Which part of my patch changes the return value? >> >> Thanks, >> Gili >> >> Trent Jarvi wrote: >>> On Wed, 15 Apr 2009, cowwoc wrote: >>> >>>> Hi, >>>> >>>> Please review the attached patch. >>>> >>>> - fixes disableReceiveTimeout() so reads now block until data is >>>> available. >>>> - receive timeouts and threshold handling is now more consistent >>>> across all implementations >>>> >>> >>> Hi Gili, >>> >>> This looks good to me. One 'minor' issue is that you are returning >>> -1 instead of 0 now on timeout. It is fair to say timeouts are the >>> same as the end of input but that is new behavior in rxtx we should >>> warn existing users about so they can adjust their code. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >> From cowwoc at bbs.darktech.org Wed Apr 15 19:30:08 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Wed, 15 Apr 2009 21:30:08 -0400 Subject: [Rxtx] Java5 support In-Reply-To: References: <49E631BF.9040501@bbs.darktech.org> <9DA32B4D8579AF44AD96C1CC2E9C518D0346E9EB@MTL-MSG-02.cgiclients.com> Message-ID: <49E68A20.80209@bbs.darktech.org> Trent Jarvi wrote: > The project isn't interested in breaking projects or changing the API. > That said, we do allow some extensions to be added that are clearly marked > as such. These extensions are all in the weird science category - they > are not alternatives to doing what the API can already do or even > something many people would want to use some of the time. We could define rxtx-specific classes in gnu.io that extend those in javax.comm so users would enjoy both backwards compatibility as well as rxtx-specific extensions. > The gnu.io namespace is used to avoid polluting of the javax.comm > namespace. There are a number of reasons why we could be concerned about > using javax.comm including political and/or legal questions but the main > reason is a project like rxtx should do no harm. Did anyone from Sun \take issue with the aforementioned approach (gnu.io extending javax.comm)? Gili > On Wed, 15 Apr 2009, Dyer, Tristan wrote: > >> That's weird. >> >> All I had to do to get my project running on RxTx was to change >> javax.comm to gnu.io >> >> I assume the reason for the fork to gnu.io was precisely to preserve >> compatibility with javax.comm. Unless Sun is willing to give you a TCK >> (or someone wants to pay for it) you wouldn't be able to provide any of >> the "new" javax.comm 3.0 feature set to windows and call it javax.comm, >> and as a side effect you get to keep the api consistent across platforms >> as well. Apache has been in a pissing fight with Sun for a couple years >> about this in regards to Harmony. >> >> As I remember rxtx was a lower level that suns CommAPI jar could talk >> to, to provide javax.comm on linux originally. With sun only providing >> CommAPI for some environments it became necessary to fork. >> >> At least that's how I assume it got here. >> >> Tristan >> >> >> -----Original Message----- >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >> Of cowwoc >> Sent: Wednesday, April 15, 2009 4:13 PM >> To: rxtx at qbang.org >> Subject: Re: [Rxtx] Java5 support >> >>> A recent post reminded me of this old thread that I do not think got >> any >>> replies. >>> >>> Here is my take on the subject (of improving the API): >>> >>> Please do not 'improve' the API! >>> >>> Serial port is an old, simple and mature thing. Let's keep it that >> way. >>> Very little will be gained by 'improving' it. It is already too bad >>> that Sun spoiled the internals of javax.comm in version 3,0 so that >> the >>> gnu.io package had to be coined. That is a nuisance but nothing >> compared to >>> what happens if we start 'improve' the API and make it incompatible >> with >>> Java Comm API. >>> >>> Even additions should be resisted as this will encourage people to >> write >>> code that is not compatible with the 'standard' Java Comm API. The >> world >>> does not need more standards but better compliance to existing >> standards. >>> If someone feels things like generics/iterators for are needed it is >> simple >>> to wrap the rxtx or java comm classes into classes to implement these >>> new language features without changing the API. >>> >>> rxtx us great and many thanks and cudos to the maintainers and >> creators but >>> it is lamentable that something this basic needs to be addressed >> outside >>> standard JRE. Not to mention being able to do basic USB stuff in >> Java/std >>> JRE in cross platform deployable fashion. >>> >>> br Kusti >> Hi Kusti, >> >> I must be missing something... I thought the entire point of forking >> >> off gnu.io was to innovate the API in a different direction than >> javax.comm, otherwise why wouldn't you stick to the standard API? >> >> Thanks, >> Gili >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Apr 15 20:19:01 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 15 Apr 2009 20:19:01 -0600 (MDT) Subject: [Rxtx] Timeout patch In-Reply-To: <49E68944.3050808@bbs.darktech.org> References: <49E64A4A.1050806@bbs.darktech.org> <49E6734E.4010809@bbs.darktech.org> <49E68944.3050808@bbs.darktech.org> Message-ID: Hi Gili, Your glowing review obviously means you have not read termios.c :) I'm not against the type of changes like you suggest. I do think they will need bake time and we have people waiting for what we have now. Putting proactive changes in the following release would be fine. The returning -1 issues are wrong and should be fixed. We can do that now. Regarding C/C++, I think the best thing to do for this project is push as much logic as is possible out of the C files and into Java. Use Java for the objects and C to perform as little as possible. This is a compromise in a sense; C++ is perfectly fine and would work. C++ could even be easier to read and probably would avoid some bugs - especial with C strings. I really don't want to build g++ cross compilers for all the platforms we do in the ToyBox. In practice, adding g++ into the mix is an order of magnitude harder to get working. If we can avoid using C++ completely, there is a measurable advantage in what we can easily deliver. http://rxtx.qbang.org//ToyBox Proof of concept: http://rxtx.qbang.org/ToyBox/2.1-7-build1/Linux/glibc-2.3.5/ On Wed, 15 Apr 2009, cowwoc wrote: > Hi Trent, > > Please modify the Javadoc to read that timeouts will return 0. > > PS: The rxtx source contains plenty of ... questionable ... lines of code. > The following items come to mind: > > 1) In serial_read() we return -1 on various error codes instead of throwing > the appropriate exception back into the Java layer. > 2) Some Java methods print error messages to stdout instead of throwing > exceptions on invalid input. > 3) #ifdef LIFE_IS_GOOD (is this ever used?) and "/* Baby did a bad baad > thing */". Ifdef and comments like this litter the code. > 4) Most files use C-language instead of C++. I am not advocating fancy C++ > but rather C code wrapped in objects. Moving variable declarations closer to > their usage and perhaps grouping related methods into cohesive classes would > improve readability. > > I know this is an open-source project, but the quality of the code > freaks me out :) Is there any resistance to fixing some of these problems? > > Gili > > Trent Jarvi wrote: >> >> Hi Gili, >> >> I guess the documentation just needs to be clear and consistant (which it >> really wasn't before). This is what caught my eye but looking above it, I >> see the previous documentation mentions -1 in places too. >> >> -*timeout threshold Behavior >> -*------------------------------------------------------------------------ >> -*0 0 blocks until 1 byte is available >> -*>0 0 blocks until timeout occurs, returns 0 on timeout >> -*>0 >0 blocks until timeout or reads threshold bytes, >> - returns 0 on timeout >> -*0 >0 blocks until reads threshold bytes >> - */ >> + * timeout threshold Behavior >> + * >> --------------------------------------------------------------------------- >> + * < 0 <= 0 blocks until any data is available. >> + * < 0 > 0 blocks until {@code min(threshold, b.len)} >> bytes are available. >> + * >=0 <=0 blocks for {@code timeout} ms or until any >> data is available. Returns -1 on timeout. >> + * >=0 > 0 blocks for {@code timeout} ms or until {@code >> min(threshold, b.len)} bytes are available. Returns -1 on timeout. >> >> >> >> On Wed, 15 Apr 2009, cowwoc wrote: >> >>> >>> Actually returning -1 on timeout would be bug on my part. I believe >>> that InputStream is expecting us to return 0 in such a case. Which part of >>> my patch changes the return value? >>> >>> Thanks, >>> Gili >>> >>> Trent Jarvi wrote: >>>> On Wed, 15 Apr 2009, cowwoc wrote: >>>> >>>>> Hi, >>>>> >>>>> Please review the attached patch. >>>>> >>>>> - fixes disableReceiveTimeout() so reads now block until data is >>>>> available. >>>>> - receive timeouts and threshold handling is now more consistent across >>>>> all implementations >>>>> >>>> >>>> Hi Gili, >>>> >>>> This looks good to me. One 'minor' issue is that you are returning -1 >>>> instead of 0 now on timeout. It is fair to say timeouts are the same as >>>> the end of input but that is new behavior in rxtx we should warn existing >>>> users about so they can adjust their code. >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> >>> > From tjarvi at qbang.org Wed Apr 15 21:38:29 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 15 Apr 2009 21:38:29 -0600 (MDT) Subject: [Rxtx] Java5 support In-Reply-To: <49E68A20.80209@bbs.darktech.org> References: <49E631BF.9040501@bbs.darktech.org> <9DA32B4D8579AF44AD96C1CC2E9C518D0346E9EB@MTL-MSG-02.cgiclients.com> <49E68A20.80209@bbs.darktech.org> Message-ID: On Wed, 15 Apr 2009, cowwoc wrote: > Trent Jarvi wrote: >> The project isn't interested in breaking projects or changing the API. That >> said, we do allow some extensions to be added that are clearly marked as >> such. These extensions are all in the weird science category - they are >> not alternatives to doing what the API can already do or even something >> many people would want to use some of the time. > > We could define rxtx-specific classes in gnu.io that extend those in > javax.comm so users would enjoy both backwards compatibility as well as > rxtx-specific extensions. > >> The gnu.io namespace is used to avoid polluting of the javax.comm >> namespace. There are a number of reasons why we could be concerned about >> using javax.comm including political and/or legal questions but the main >> reason is a project like rxtx should do no harm. > > Did anyone from Sun \take issue with the aforementioned approach > (gnu.io extending javax.comm)? > It would take more than an opinion from someone at Sun before we moved like that. javax.comm (a namespace grandfathered into the JSR) is a broken namespace with a special 'generic' legacy release that may be discontinued at any time. The people using rxtx are interested in what javax.comm was in version 2.0. Not the 3.0 currently offered which appears to be a quick fix for a business need Sun satisfied on Solaris. Why would we ever depend upon (extend) this namespace? -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Thu Apr 16 10:38:42 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Thu, 16 Apr 2009 12:38:42 -0400 Subject: [Rxtx] Java5 support In-Reply-To: References: <49E631BF.9040501@bbs.darktech.org> <9DA32B4D8579AF44AD96C1CC2E9C518D0346E9EB@MTL-MSG-02.cgiclients.com> <49E68A20.80209@bbs.darktech.org> Message-ID: <49E75F12.7010603@bbs.darktech.org> Trent Jarvi wrote: > It would take more than an opinion from someone at Sun before we moved > like that. > > javax.comm (a namespace grandfathered into the JSR) is a broken > namespace with a special 'generic' legacy release that may be > discontinued at any time. The people using rxtx are interested in what > javax.comm was in version 2.0. Not the 3.0 currently offered which > appears to be a quick fix for a business need Sun satisfied on Solaris. > > Why would we ever depend upon (extend) this namespace? I was under the impression that javax.comm 3.0 was backwards compatible against 2.0... What changes in 3.0 do the rxtx folk object to? The way I see it, gnu.io suffers from the following pain points: 1) Not backwards compatible with standard API 2) Non-existent Javadoc for most of the API 3) Tiny community base, non-existent commercial support, questionable code quality. I still don't understand enough about the reasoning behind the namespace fork. I'm all for forking if we take the opportunity to innovate the API, but if you're going to keep it almost identical I'd be in favor of just having gnu.io extend javax.comm. Again, I might change my mind once I understand your reasoning better but that's how I feel now. Gili From bschlining at gmail.com Thu Apr 16 12:04:05 2009 From: bschlining at gmail.com (Brian Schlining) Date: Thu, 16 Apr 2009 11:04:05 -0700 Subject: [Rxtx] Java5 support In-Reply-To: <49E75F12.7010603@bbs.darktech.org> References: <49E631BF.9040501@bbs.darktech.org> <9DA32B4D8579AF44AD96C1CC2E9C518D0346E9EB@MTL-MSG-02.cgiclients.com> <49E68A20.80209@bbs.darktech.org> <49E75F12.7010603@bbs.darktech.org> Message-ID: > > > I was under the impression that javax.comm 3.0 was backwards > compatible > against 2.0... What changes in 3.0 do the rxtx folk object to? I haven't tried 3.0, since my target platforms are usually Mac or Windows. I can say that when Sun dropped Windows support of Javacomm, it was quite a slap in the face. The real kicker was that they removed the downloads for version 2.0 too. So that left folks who were using Sun's API in a pickle. > > The way I see it, gnu.io suffers from the following pain points: > > 1) Not backwards compatible with standard API Hmmm, not exactly true. When Sun removed Javacomm 2.0, RXTX was a real savior, I only had to change the namespace in my code and everything worked. > 2) Non-existent Javadoc for most of the API Sort of. Since RXTX's API is the same as Sun's, code examples and Javadocs from Sun's stuff do apply to RXTX. > 3) Tiny community base, non-existent commercial support, questionable > code quality. You really should back those assertions up with facts before make them. I can think of a number of projects here at my employer that use RXTX, so we really appreciate Trent's work as well as all the folks who have contributed patches. If you want commercial support I'm sure that if you offered enough money, Trent would work something out with you ;-). Also, there's always http://serialio.com/products/serialport/serialport.php As to the code quality, the project is open source, feel free to contribute fixes. > I still don't understand enough about the reasoning behind the > namespace fork. I'm all for forking if we take the opportunity to > innovate the API, but if you're going to keep it almost identical I'd be > in favor of just having gnu.io extend javax.comm. Again, I might change > my mind once I understand your reasoning better but that's how I feel now. > As to extending/innovating the API, RXTX is an open-source project. You can always take the code base and fork it to suit your needs, as long as you adhere to the LGPL license. Cheers -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090416/32cb4447/attachment-0002.html From paul at cometway.com Thu Apr 16 12:56:35 2009 From: paul at cometway.com (Paul Cunningham) Date: Thu, 16 Apr 2009 14:56:35 -0400 Subject: [Rxtx] Java5 support Message-ID: <91BF244D-07E4-4B30-9F9D-0DC0964045B4@cometway.com> I've been a steady lurker on this board for years and have to agree with Brian here: 1) RXTX was a savior -- long before javax.comm was dropped from Sun's repertoire. For Mac OS X users it's the ONLY option. Serial port support on the Mac has always been a sore spot for me. 2) There's nothing complicated about the javax.comm APIs and they are well Javadoc'ed all over the web. RXTX adherence to them has been very consistent. 3) RS-232 with Java is a tiny community period. If you are reading this, I'm sorry but you are a freak. Anyone doing RS-232 for unknown device "x" is a member of an even tinier community with practically no support whatsoever. However this RXTX list community is extremely well supported and every important question is addressed quickly, personally and in great detail by Trent himself. You can't get support like that from most "commercial" operations and we certainly never got that from commercial entities like Sun. Nobody here is going to hold your hand, but we will point you to any available resources that aren't already clearly spelled out on the RXTX page. You might have to learn how to download and build the package for yourself to get the latest updates and fixes, but that's just par for the course. -pc On Apr 16, 2009, at 2:04 PM, Brian Schlining wrote: > > I was under the impression that javax.comm 3.0 was backwards > compatible > against 2.0... What changes in 3.0 do the rxtx folk object to? > > I haven't tried 3.0, since my target platforms are usually Mac or > Windows. I can say that when Sun dropped Windows support of > Javacomm, it was quite a slap in the face. The real kicker was that > they removed the downloads for version 2.0 too. So that left folks > who were using Sun's API in a pickle. > > > The way I see it, gnu.io suffers from the following pain > points: > > 1) Not backwards compatible with standard API > > Hmmm, not exactly true. When Sun removed Javacomm 2.0, RXTX was a > real savior, I only had to change the namespace in my code and > everything worked. > > 2) Non-existent Javadoc for most of the API > > Sort of. Since RXTX's API is the same as Sun's, code examples and > Javadocs from Sun's stuff do apply to RXTX. > > 3) Tiny community base, non-existent commercial support, questionable > code quality. > > You really should back those assertions up with facts before make > them. > > I can think of a number of projects here at my employer that use > RXTX, so we really appreciate Trent's work as well as all the folks > who have contributed patches. If you want commercial support I'm > sure that if you offered enough money, Trent would work something > out with you ;-). Also, there's always http://serialio.com/products/serialport/serialport.php > > As to the code quality, the project is open source, feel free to > contribute fixes. > > I still don't understand enough about the reasoning behind the > namespace fork. I'm all for forking if we take the opportunity to > innovate the API, but if you're going to keep it almost identical > I'd be > in favor of just having gnu.io extend javax.comm. Again, I might > change > my mind once I understand your reasoning better but that's how I > feel now. > > As to extending/innovating the API, RXTX is an open-source project. > You can always take the code base and fork it to suit your needs, as > long as you adhere to the LGPL license. > > Cheers > > -- > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > Brian Schlining > bschlining at gmail.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090416/dd8eda0b/attachment-0002.html From cowwoc at bbs.darktech.org Thu Apr 16 14:07:41 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Thu, 16 Apr 2009 16:07:41 -0400 Subject: [Rxtx] Java5 support In-Reply-To: <91BF244D-07E4-4B30-9F9D-0DC0964045B4@cometway.com> References: <91BF244D-07E4-4B30-9F9D-0DC0964045B4@cometway.com> Message-ID: <49E7900D.3060100@bbs.darktech.org> Paul Cunningham wrote: > 2) There's nothing complicated about the javax.comm APIs and they are > well Javadoc'ed all over the web. RXTX adherence to them has been very > consistent. The fact that javax.comm has good Javadoc does not mean that gnu.io does. The latter has little or no Javadoc. Yes we could assume that gnu.io's documentation is identical to javax.comm but the fact remains that code-completion won't bring up Javadoc for gnu.io. Secondly, someone mentioned recently that although the APIs are supposed to be the same, RXTX in fact behaves noticeably different from javax.comm. The gnu.io specification needs to be nailed down one way or the other. Gili From bschlining at gmail.com Thu Apr 16 14:25:38 2009 From: bschlining at gmail.com (Brian Schlining) Date: Thu, 16 Apr 2009 13:25:38 -0700 Subject: [Rxtx] Java5 support In-Reply-To: <49E7900D.3060100@bbs.darktech.org> References: <91BF244D-07E4-4B30-9F9D-0DC0964045B4@cometway.com> <49E7900D.3060100@bbs.darktech.org> Message-ID: > > The fact that javax.comm has good Javadoc does not mean that gnu.io > does. The latter has little or no Javadoc. Yes we could assume that > gnu.io's documentation is identical to javax.comm but the fact remains > that code-completion won't bring up Javadoc for gnu.io. Gili, perhaps a highly motivated person, such as yourself, could fill in the Javadocs and contribute the patches back to RXTX? -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090416/79502619/attachment-0002.html From cowwoc at bbs.darktech.org Thu Apr 16 14:47:27 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Thu, 16 Apr 2009 16:47:27 -0400 Subject: [Rxtx] Java5 support In-Reply-To: References: <91BF244D-07E4-4B30-9F9D-0DC0964045B4@cometway.com> <49E7900D.3060100@bbs.darktech.org> Message-ID: <49E7995F.1020304@bbs.darktech.org> Brian, I have already submitted two patches for RXTX in the past week alone... I understand that Sun's decision to drop Windows and Mac support angered quite a few people but I fail to see the link between the reference implementation (which angered you) and the specification (which by all accounts is great). Why not extend their specification and completely replace the implementation? From what I've read, javax.comm 3.0's API is completely backwards compatible to 2.0. On the flip side, if you're not interested in extending javax.comm, why not refactor the gnu.io package to improve usability and I would be more than happy to contribute a completely new Javadoc. Gili Brian Schlining wrote: > The fact that javax.comm has good Javadoc does not mean that > gnu.io > does. The latter has little or no Javadoc. Yes we could assume that > gnu.io 's documentation is identical to javax.comm > but the fact remains > that code-completion won't bring up Javadoc for gnu.io . > > > Gili, perhaps a highly motivated person, such as yourself, could fill in > the Javadocs and contribute the patches back to RXTX? > > -- > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > Brian Schlining > bschlining at gmail.com From talberts at msiscales.com Thu Apr 16 14:55:50 2009 From: talberts at msiscales.com (Tim Alberts) Date: Thu, 16 Apr 2009 13:55:50 -0700 Subject: [Rxtx] RXTX Simple Demo Program Message-ID: <49E79B56.5010604@msiscales.com> I don't think it exists yet, so I'd like to propose it be done. I would like to see a demo program that opens a serial port and allows transmitting/receiving of data and configuration of ports via the RXTX gnu.io software. One of the features that was driving me to move to RXTX (aside from Sun dropping support), was the upcoming ability to use web install. I have not kept up so I'm not sure yet if that is implemented, but if/when it is, a demo program to distribute via web install would be outstanding to see from RXTX. I know that Sun has (had) a blackbox demo program that tries to open every available serial port it finds on the computer and allows for transmit/receive and configuration of the serial port. This is pretty much what I have in mind for RXTX. Is this a reasonable request? -------------- next part -------------- A non-text attachment was scrubbed... Name: talberts.vcf Type: text/x-vcard Size: 337 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20090416/3986518c/attachment-0002.vcf From tjarvi at qbang.org Thu Apr 16 14:56:35 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Apr 2009 14:56:35 -0600 (MDT) Subject: [Rxtx] Java5 support In-Reply-To: <49E7900D.3060100@bbs.darktech.org> References: <91BF244D-07E4-4B30-9F9D-0DC0964045B4@cometway.com> <49E7900D.3060100@bbs.darktech.org> Message-ID: On Thu, 16 Apr 2009, cowwoc wrote: > Paul Cunningham wrote: >> 2) There's nothing complicated about the javax.comm APIs and they are >> well Javadoc'ed all over the web. RXTX adherence to them has been very >> consistent. > > The fact that javax.comm has good Javadoc does not mean that gnu.io > does. The latter has little or no Javadoc. Yes we could assume that > gnu.io's documentation is identical to javax.comm but the fact remains > that code-completion won't bring up Javadoc for gnu.io. Secondly, > someone mentioned recently that although the APIs are supposed to be the > same, RXTX in fact behaves noticeably different from javax.comm. The > gnu.io specification needs to be nailed down one way or the other. > Hi Gili RXTX treats the javax.comm v2.0 API docs as the truth. When rxtx does not behave like the docs say, we treat it as a bug. If the bug really bothers someone, they fix it. That said, there will be behavior differences between the implementations. RXTX is not a 'bug per bug' implementation of javax.comm. Many default settings are not documented and can differ also. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Apr 16 15:47:24 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Apr 2009 15:47:24 -0600 (MDT) Subject: [Rxtx] Java5 support In-Reply-To: <49E7995F.1020304@bbs.darktech.org> References: <91BF244D-07E4-4B30-9F9D-0DC0964045B4@cometway.com> <49E7900D.3060100@bbs.darktech.org> <49E7995F.1020304@bbs.darktech.org> Message-ID: On Thu, 16 Apr 2009, cowwoc wrote: > On the flip side, if you're not interested in extending javax.comm, why > not refactor the gnu.io package to improve usability and I would be more > than happy to contribute a completely new Javadoc. Hi Gili, Changing the API to use the latest offerings in JREs is not in itself a good reason to break an API. If the functionality is there, this library is better off not changing because many applications count on that API remaining stable. If you have some usability issues that hold merit beyond your personal preferences and make sense to most of the people here, RXTX can change if it is obviously the right thing to do. -- Trent Jarvi tjarvi at qbang.org From paul at cometway.com Thu Apr 16 15:52:18 2009 From: paul at cometway.com (Paul Cunningham) Date: Thu, 16 Apr 2009 17:52:18 -0400 Subject: [Rxtx] Java5 support In-Reply-To: <49E7900D.3060100@bbs.darktech.org> References: <91BF244D-07E4-4B30-9F9D-0DC0964045B4@cometway.com> <49E7900D.3060100@bbs.darktech.org> Message-ID: <9146C76F-17D8-468D-A0F2-CAC9512BCDD6@cometway.com> Code completion... isn't that where you stub out some methods, check it into CVS, and the next day find out that someone else finished your work? ;-) Seemingly your project has exposed RXTX to more finicky devices than the ones I have worked with. I can understand why better Javadocs would be useful if you are using IDEs as a tool to learn and remember your APIs, and you sound qualified enough to contribute information about the kinds of idiosyncrasies between javax.comm and gui.io to the RXTX project. I also understand that you have read the javax.comm 3.0 APIs and are upset that no one has actually implemented them. An updated specification and your keen interest in seeing it implemented is apparently not enough to make that happen in a world where RS-232 is only used for legacy support of devices with no hope for firmware updates. -pc On Apr 16, 2009, at 4:07 PM, cowwoc wrote: > Paul Cunningham wrote: >> 2) There's nothing complicated about the javax.comm APIs and they >> are well Javadoc'ed all over the web. RXTX adherence to them has >> been very consistent. > > The fact that javax.comm has good Javadoc does not mean that gnu.io > does. The latter has little or no Javadoc. Yes we could assume that > gnu.io's documentation is identical to javax.comm but the fact > remains that code-completion won't bring up Javadoc for gnu.io. > Secondly, someone mentioned recently that although the APIs are > supposed to be the same, RXTX in fact behaves noticeably different > from javax.comm. The gnu.io specification needs to be nailed down > one way or the other. > > Gili > > From paul at cometway.com Thu Apr 16 16:14:16 2009 From: paul at cometway.com (Paul Cunningham) Date: Thu, 16 Apr 2009 18:14:16 -0400 Subject: [Rxtx] Java5 support In-Reply-To: <9146C76F-17D8-468D-A0F2-CAC9512BCDD6@cometway.com> References: <91BF244D-07E4-4B30-9F9D-0DC0964045B4@cometway.com> <49E7900D.3060100@bbs.darktech.org> <9146C76F-17D8-468D-A0F2-CAC9512BCDD6@cometway.com> Message-ID: <47F476E8-5F95-4521-A437-11622583210F@cometway.com> btw, i mean no disrespect to anyone actively developing an RS-232 interfaces for new devices. in fact my most recent project involved a freescale chip using a UART- to-USB chip, as i have no idea how to go about interfacing USB devices to Java. RXTX behaved very well, even when the USB driver didn't. is there anything resembling javax.comm for USB? -pc On Apr 16, 2009, at 5:52 PM, Paul Cunningham wrote: > in a world where RS-232 is > only used for legacy support of devices with no hope for firmware > updates. From tjarvi at qbang.org Thu Apr 16 16:50:12 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Apr 2009 16:50:12 -0600 (MDT) Subject: [Rxtx] Java5 support In-Reply-To: <47F476E8-5F95-4521-A437-11622583210F@cometway.com> References: <91BF244D-07E4-4B30-9F9D-0DC0964045B4@cometway.com> <49E7900D.3060100@bbs.darktech.org> <9146C76F-17D8-468D-A0F2-CAC9512BCDD6@cometway.com> <47F476E8-5F95-4521-A437-11622583210F@cometway.com> Message-ID: Hi Paul, JSR 80 is USB HID support. http://javax-usb.org/ http://jcp.org/aboutJava/communityprocess/final/jsr080/index.html On Thu, 16 Apr 2009, Paul Cunningham wrote: > btw, i mean no disrespect to anyone actively developing an RS-232 > interfaces for new devices. > > in fact my most recent project involved a freescale chip using a UART- > to-USB chip, as i have no idea how to go about interfacing USB devices > to Java. RXTX behaved very well, even when the USB driver didn't. > > is there anything resembling javax.comm for USB? -pc > > > On Apr 16, 2009, at 5:52 PM, Paul Cunningham wrote: > >> in a world where RS-232 is >> only used for legacy support of devices with no hope for firmware >> updates. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From cowwoc at bbs.darktech.org Thu Apr 16 16:57:43 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Thu, 16 Apr 2009 18:57:43 -0400 Subject: [Rxtx] Java5 support In-Reply-To: References: <91BF244D-07E4-4B30-9F9D-0DC0964045B4@cometway.com> <49E7900D.3060100@bbs.darktech.org> <9146C76F-17D8-468D-A0F2-CAC9512BCDD6@cometway.com> <47F476E8-5F95-4521-A437-11622583210F@cometway.com> Message-ID: <49E7B7E7.9050302@bbs.darktech.org> Last time I looked this, there was no usable Windows version. Gili Trent Jarvi wrote: > Hi Paul, > > JSR 80 is USB HID support. > > http://javax-usb.org/ > http://jcp.org/aboutJava/communityprocess/final/jsr080/index.html > > On Thu, 16 Apr 2009, Paul Cunningham wrote: > >> btw, i mean no disrespect to anyone actively developing an RS-232 >> interfaces for new devices. >> >> in fact my most recent project involved a freescale chip using a UART- >> to-USB chip, as i have no idea how to go about interfacing USB devices >> to Java. RXTX behaved very well, even when the USB driver didn't. >> >> is there anything resembling javax.comm for USB? -pc >> >> >> On Apr 16, 2009, at 5:52 PM, Paul Cunningham wrote: >> >>> in a world where RS-232 is >>> only used for legacy support of devices with no hope for firmware >>> updates. >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Apr 16 17:02:49 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Apr 2009 17:02:49 -0600 (MDT) Subject: [Rxtx] RXTX Simple Demo Program In-Reply-To: <49E79B56.5010604@msiscales.com> References: <49E79B56.5010604@msiscales.com> Message-ID: On Thu, 16 Apr 2009, Tim Alberts wrote: > I don't think it exists yet, so I'd like to propose it be done. I would like > to see a demo program that opens a serial port and allows > transmitting/receiving of data and configuration of ports via the RXTX gnu.io > software. > > One of the features that was driving me to move to RXTX (aside from Sun > dropping support), was the upcoming ability to use web install. I have not > kept up so I'm not sure yet if that is implemented, but if/when it is, a demo > program to distribute via web install would be outstanding to see from RXTX. > > I know that Sun has (had) a blackbox demo program that tries to open every > available serial port it finds on the computer and allows for > transmit/receive and configuration of the serial port. This is pretty much > what I have in mind for RXTX. > > Is this a reasonable request? > Hi Tim, It is a great request. I don't know if anyone will write tha application though. We could include it with rxtx as a demo like BlackBox was with Sun's commapi. But.. You can run Sun's BlackBox source code through the ChangePackage.sh and use BlackBox with rxtx 2.1/2.2 for personal use. ChangePackage.sh is in the contrib directory with the rxtx source code. As I recall, there was just one minor modification required - BlackBox had a hard coded number of ports which could cause problems. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Apr 16 20:25:29 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Apr 2009 20:25:29 -0600 (MDT) Subject: [Rxtx] Timeout patch In-Reply-To: <49E64A4A.1050806@bbs.darktech.org> References: <49E64A4A.1050806@bbs.darktech.org> Message-ID: On Wed, 15 Apr 2009, cowwoc wrote: > Hi, > > Please review the attached patch. > > - fixes disableReceiveTimeout() so reads now block until data is available. > - receive timeouts and threshold handling is now more consistent across all > implementations > Attached is the core change to serial Gili has suggested. I ran tests that cover about 40% of the serial code without regressions. If you happen to use the same 40%, you are safe :) Otherwise, I suggest trying the changes. I'd like to hear if this fixes issues for anyone. I put some binaries for win32, Mac and linux32 here: ftp://ftp.qbang.org/pub/rxtx/test-timeout.zip Unfortunately, The original patch tries to do several things. Some of the changes are not correct and require further review. This is just the timeout portion for serial code which I've reviewed and tested. -- Trent Jarvi tjarvi at qbang.org -------------- next part -------------- Index: src/SerialImp.c =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v retrieving revision 1.46.2.203 diff -u -r1.46.2.203 SerialImp.c --- src/SerialImp.c 19 Mar 2009 03:27:48 -0000 1.46.2.203 +++ src/SerialImp.c 17 Apr 2009 02:05:48 -0000 @@ -3298,6 +3298,8 @@ if (vtime < 0){ timeout = 0; + if (threshold <= 0) + threshold = 1; } else if (vtime == 0){ timeout = 1; Index: src/gnu/io/RXTXPort.java =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/gnu/io/RXTXPort.java,v retrieving revision 1.27.2.76 diff -u -r1.27.2.76 RXTXPort.java --- src/gnu/io/RXTXPort.java 13 Nov 2008 23:37:45 -0000 1.27.2.76 +++ src/gnu/io/RXTXPort.java 17 Apr 2009 02:05:48 -0000 @@ -1,7 +1,7 @@ /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. -| Copyright 1997-2008 by Trent Jarvi tjarvi at qbang.org and others who +| Copyright 1997-2009 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at @@ -398,19 +398,16 @@ { if (debug) z.reportln( "RXTXPort:enableReceiveTimeout() called"); - if( time >= 0 ) - { - timeout = time; - NativeEnableReceiveTimeoutThreshold( time , threshold, - InputBuffer ); - } - else + if( time < 0 ) { throw new IllegalArgumentException ( "Unexpected negative timeout value" ); } + timeout = time; + NativeEnableReceiveTimeoutThreshold( timeout , threshold, + InputBuffer ); if (debug) z.reportln( "RXTXPort:enableReceiveTimeout() returning"); } @@ -444,19 +441,16 @@ { if (debug) z.reportln( "RXTXPort:enableReceiveThreshold( " + thresh + " ) called"); - if(thresh >=0) - { - threshold=thresh; - NativeEnableReceiveTimeoutThreshold(timeout, threshold, - InputBuffer); - } - else /* invalid thresh */ + if(thresh < 1) { throw new IllegalArgumentException ( - "Unexpected negative threshold value" + "Threshold value must be possitive" ); } + threshold=thresh; + NativeEnableReceiveTimeoutThreshold(timeout, threshold, + InputBuffer); if (debug) z.reportln( "RXTXPort:enableReceiveThreshold( " + thresh + " ) returned"); } @@ -465,8 +459,12 @@ public void disableReceiveThreshold() { if (debug) - z.reportln( "RXTXPort:disableReceiveThreshold() called and returning"); - enableReceiveThreshold(0); + z.reportln( "RXTXPort:disableReceiveThreshold(0) called"); + threshold = 0; + NativeEnableReceiveTimeoutThreshold(timeout, threshold, + InputBuffer); + if (debug) + z.reportln( "RXTXPort:disableReceiveThreshold(0) returning"); } /** * @return int the recieve threshold @@ -1415,7 +1413,7 @@ */ int Minimum = len; - if( threshold==0 ) + if( threshold < 1 ) { /* * If threshold is disabled, read should return as soon @@ -1528,7 +1526,7 @@ */ int Minimum = len; - if( threshold==0 ) + if( threshold < 1 ) { /* * If threshold is disabled, read should return as soon From cowwoc at bbs.darktech.org Thu Apr 16 23:09:03 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Fri, 17 Apr 2009 01:09:03 -0400 Subject: [Rxtx] Problems with read timeout In-Reply-To: References: <49E64A4A.1050806@bbs.darktech.org> Message-ID: <49E80EEF.6000503@bbs.darktech.org> I've been playing with the read timeout behavior and I'm seeing some non-intuitive behavior. I've got an endless loop that does the following: 1) COM1 and COM2 are connected to one another. They are opened at 300 baud, with read timeout of 300ms. 2) COM1 writes "CONNECTION" 3) COM2 reads "CONNECTION" 4) COM2 writes "CONNECTION 9600 8 NONE 1 RTS/CTS" and tries a read operation. 5) COM1 receives "CONNECTION 960" when suddenly COM2 hits the 300ms read timeout. COM2 gets an IOException (caused by the timeout), and closes the serial port. 6) COM1 never gets the full message because the connection was closed in middle of sending. I want step 4 to block until COM1 receives the full message before it attempts the read operation but I'm not sure how to achieve this. I was somewhat expecting the write() or flush() operation to block until the send was complete... Any ideas? Gili From Steffen.DETTMER at ingenico.com Fri Apr 17 03:55:01 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 17 Apr 2009 11:55:01 +0200 Subject: [Rxtx] Java5 support In-Reply-To: <49E7900D.3060100@bbs.darktech.org> References: <91BF244D-07E4-4B30-9F9D-0DC0964045B4@cometway.com> <49E7900D.3060100@bbs.darktech.org> Message-ID: <20090417095501.GL13774@elberon.bln.de.ingenico.com> Hi, I cannot resist to make some comments, too :) In short, I think rxtx and gnu.io are good. Even if the API is `accidently' the same as javax.comm, logically rxtx IMHO is independent. It offers functionality an application can use - it does not need javax.comm at all. - IMHO Javadoc of javax.comm is /not/ good. What does it help to document `DATABITS_5' with `5 data bit format'? The documentation of SerialPort to me looks like what a less interested, less motivated student would write after failing a code review because of lack of documentation (review of course will fail again, even worse, because identifier <-> microdoc redundancy :)) There are so many issues with the docs... Also, those `optional functionality' is IMHO just a design bug. An interface is to define the interface, the features and functions that are available. Now Java has interfaces with optional functions. loooooooooool This ends that you have an application using this interface correctly and having a correct implementation of this interface but they do not work together because in fact they are using a different interface. It was hidden to the compiler by using `optional methods'. Just great. - namespace gnu.io IMHO is correct (well, don't know if gnu is correct etc, I just mean different from javax is) namespaces are exactly invented for such cases. Maybe gnu.io could implement javax.comm interfaces, maybe not. If someone really has a problem with package names, why not simply perl -npi -e 's/gnu.io/javax.comm/g' *.java could be some rule in some Makefile. - Some `wrapper' adding usability to the Java APIs (like InputStream) IMHO is essential and required anyway. I dislike the APIs, for instance InputStream and those. It is almost impossible to write really correct code with it. It is sufficient for simple GUI stuff you can kill if it blocks or so, but for e.g. server applications IMHO it is not sufficient. Timeouts are needed and so on. Well, this would just lead to a API discussion which would be a different topic. Because a wrapper is needed, package namings IMHO are no issue. Personally, I would prefer for some future version to drop the logical dependency to the stange javax.comm.SerialPort thingy, instead have a clean simple but specific JNI interface. This is `an implementation detail', so rxtx can do whatever is appropriate :) - this java event and multi-threading mixes IMHO often are just a workaround for a missing select(2). On linux, for instance, select and related functions are really strong. You can select in one and the same call a serial port, a TCP socket and a file if you want. In recently it seems Java people started to understand and did some new (not that new, java5 IIRC :)) APIs allowing things like that. They also introduced a new `ByteBuffer' for JNI performance IIRC. Applications using this also are not compatible to javax.comm. Also, the abstraction isn't sufficient IMHO, because applications cannot use InputStream because of missing timeouts, so they must use e.g. SerialPort and now all abstraction is gone, because timeouts for a SerialPort and SocketChannel are completely different in Java (unlike select(), which does abstract). So I think the `break' from javax.comm should be no issue. - rxtx is not required to provide high performance (I think). Of course it should be fast and stable, but IMHO no high performance is needed; typical applications probably just have to work with a few serial ports. When high performance is an issue, I think it would be required that on the JNI interface multiple ports can be processed with a single thread and a single call, for instance if data is buffered per port and the single call processes all active ports or so. In such a case I think it would be likely that a kind of BSD socket API interface would result as internal JNI interface, but this also is another topic. I think 64 port serial console servers are rare today and probably not implemented in Java :-) oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Steffen.DETTMER at ingenico.com Fri Apr 17 04:24:16 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 17 Apr 2009 12:24:16 +0200 Subject: [Rxtx] Problems with read timeout In-Reply-To: <49E80EEF.6000503@bbs.darktech.org> References: <49E64A4A.1050806@bbs.darktech.org> <49E80EEF.6000503@bbs.darktech.org> Message-ID: <20090417102416.GM13774@elberon.bln.de.ingenico.com> Hi, * cowwoc wrote on Fri, Apr 17, 2009 at 01:09 -0400: > I want step 4 to block until COM1 receives the full message before it Do you really want to block? Block means infinite timeout. In case of a serial communication issue (or such) your application will just hang. I think, usually, timeouts are no errors. On timeouts, often it is not correct to close the communication mean where it occured. > attempts the read operation but I'm not sure how to achieve > this. I was somewhat expecting the write() or flush() operation > to block until the send was complete... Any ideas? Typically you cannot know when the send really happend. OS buffers probably many bytes and UART several bits at least. With hardware flow control it might happen that sending a byte takes long time (seconds, minutes or even more). For testing your new implementation maybe you use some other tool (application or hardware, like a modem) to avoid that e.g. receive issues on one side are looking like send issues on the other - or so. Maybe you start some timer for a total timeout and call read in a loop (with the remaining time of the timer as timeout, half of the remaining time limited to a big fixed value or a small fixed value to poll)? When using small timeouts (lets say below 100 ms, not sure if 300 ms could be a problem too), be aware that because of interupt delays, other processes consuming CPU time or whatever reasons an operation can take longer, so a timer is expired but no timeout happend. Sometimes even (debug) log file writing can take so much or even more time. So for a more robust implementation it could help to invoke a read with a very short timeout right after the timer expired. If there is some (internally OS buffered) data it will be returned (this should not considered a timeout, i.e. not throw an exception). oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Kustaa.Nyholm at planmeca.com Fri Apr 17 05:54:50 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 17 Apr 2009 14:54:50 +0300 Subject: [Rxtx] Java5 support In-Reply-To: <9146C76F-17D8-468D-A0F2-CAC9512BCDD6@cometway.com> Message-ID: > From: Paul Cunningham > [snip] in a world where RS-232 is only used for legacy support of devices > with no hope for firmware updates. This is not entirely true. I mean there is a lot more to RS-232 than 'legacy support of devices with no hope for firmware updates'. The alternatives to RS-232 (USB comes to mind) are not that attractive to many niche device / system manufactures because implementing them and supporting them, especially across many platforms is often beyond their means and capabilities. Hence even new designs are based on RS232 on way or the other. RS232 is about the only easy(ish) way to access the outside world from in a relatively device and platform independent manor. Also even when implementing USB is feasible the other limitation of USB may make RS232 much more attractive proposition. Five meter cable length limitation and the utter unpracticality of implementing galvanic isolation come to mind. br Kusti BTW I did not quite get what the rest of the sentence ('with no hope for firmware updates') referred to. From Kustaa.Nyholm at planmeca.com Fri Apr 17 05:56:05 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 17 Apr 2009 14:56:05 +0300 Subject: [Rxtx] FW: Java5 support In-Reply-To: Message-ID: Ooops, sorry Gili, this was meant for the list. > From: Kustaa Nyholm > Date: Fri, 17 Apr 2009 14:41:48 +0300 > To: cowwoc > Conversation: [Rxtx] Java5 support > Subject: Re: [Rxtx] Java5 support > > > Nor Mac support and I think the Linux support is not complete either. > > It is a pity. I'm afraid it reflects the state of desktop Java which is sad > because there really are no alternative to Java for writing rich desktop > applications that look reasonably native on each of the three major platforms > in mostly platform agnostic way. > > br Kusti > >> From: cowwoc >> >> Last time I looked this, there was no usable Windows version. >> >> Gili >> >> Trent Jarvi wrote: >>> Hi Paul, >>> >>> JSR 80 is USB HID support. >>> >>> http://javax-usb.org/ >>> http://jcp.org/aboutJava/communityprocess/final/jsr080/index.html >>> >>> On Thu, 16 Apr 2009, Paul Cunningham wrote: >>> >>>> btw, i mean no disrespect to anyone actively developing an RS-232 >>>> interfaces for new devices. >>>> >>>> in fact my most recent project involved a freescale chip using a UART- >>>> to-USB chip, as i have no idea how to go about interfacing USB devices >>>> to Java. RXTX behaved very well, even when the USB driver didn't. >>>> >>>> is there anything resembling javax.comm for USB? -pc >>>> >>>> >>>> On Apr 16, 2009, at 5:52 PM, Paul Cunningham wrote: >>>> >>>>> in a world where RS-232 is >>>>> only used for legacy support of devices with no hope for firmware >>>>> updates. >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx ------ End of Forwarded Message From Kustaa.Nyholm at planmeca.com Fri Apr 17 05:56:42 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 17 Apr 2009 14:56:42 +0300 Subject: [Rxtx] FW: Java5 support In-Reply-To: Message-ID: Oops again, this was meant for the list. Sorry. ------ Forwarded Message > From: Kustaa Nyholm > Date: Fri, 17 Apr 2009 14:38:36 +0300 > To: Steffen DETTMER > Conversation: [Rxtx] Java5 support > Subject: Re: [Rxtx] Java5 support > >> From: Steffen DETTMER > >> - IMHO Javadoc of javax.comm is /not/ good....[SNIP] > Maybe documentation in javax.comm isnot first class but it is better than no > documentation. > > Having said that I have no desire to get this documentation copied over to > gnu.io I can just as well use the little bits I need from the javadocs of > javax.comm. > > After all this is a very small API and I would very much like it to stay that > way.e in some Makefile. >> >> - Some `wrapper' adding usability to the Java APIs (like >> InputStream) IMHO is essential and required anyway. >> > Me for one definitely don't need anywrapper, I'm happy with the way > the API is. javax.comm/gnu.io is a very low level abstraction of > the under laying hardware, and IMO it should stay that way. Anyone > interested in a better wrapper is of course free to implement and > publish one, if so inclined. But let's keep this in perspective, > serial port is small, but sometimes crucial, well established thing > that will not get better by braking things by improving it. > >> I dislike the APIs, for instance InputStream and those. It is >> almost impossible to write really correct code with it. It is >> sufficient for simple GUI stuff you can kill if it blocks or >> so, but for e.g. server applications IMHO it is not sufficient. >> Timeouts are needed and so on. > Would be fascinating to learn more about this as I've never had > any problem with APIs. > >> >> Well, this would just lead to a API discussion which would be a >> different topic. >> >> Because a wrapper is needed, package namings IMHO are no issue. >> Personally, I would prefer for some future version to drop the >> logical dependency to the stange javax.comm.SerialPort thingy, >> instead have a clean simple but specific JNI interface. >> This is `an implementation detail', so rxtx can do whatever is >> appropriate :) >> > I would suspect that most user would not welcome anything that brakes > compatibility with the existing API. Let's improve something in > a separate wrapper project. >> >> >> - this java event and multi-threading mixes IMHO often are just a >> workaround for a missing select(2). On linux, for instance, >> select and related functions are really strong. You can select >> in one and the same call a serial port, a TCP socket and a file >> if you want. In recently it seems Java people started to >> understand and did some new (not that new, java5 IIRC :)) APIs >> allowing things like that. They also introduced a new >> `ByteBuffer' for JNI performance IIRC. >> >> Applications using this also are not compatible to javax.comm. >> Also, the abstraction isn't sufficient IMHO, because >> applications cannot use InputStream because of missing >> timeouts, so they must use e.g. SerialPort and now all >> abstraction is gone, because timeouts for a SerialPort and >> SocketChannel are completely different in Java (unlike >> select(), which does abstract). > I'm not sure I followed/understood everything above but it smelt > like *one* POV and I suspect, that if I had understood what I read, that > I would have had a different POV. >> >> So I think the `break' from javax.comm should be no issue. > Depending on what above means this could be huge issues for many of us. > But I think I've said that several times already. >> >> >> >> - rxtx is not required to provide high performance (I think). > Agree. >> >> Of course it should be fast and stable, but IMHO no high >> performance is needed; typical applications probably just have >> to work with a few serial ports. > Agree. >> >> When high performance is an issue, I think it would be required >> that on the JNI interface multiple ports can be processed with >> a single thread and a single call, for instance if data is >> buffered per port and the single call processes all active >> ports or so. In such a case I think it would be likely that a >> kind of BSD socket API interface would result as internal JNI >> interface, but this also is another topic. > This paragraph had so many assumptions that I refrain from commenting > other than that it portrays one POV which again I suspect I do not > care for. >> >> I think 64 port serial console servers are rare today and >> probably not implemented in Java :-) >> >> >> oki, >> >> Steffen >> > br Kusti ------ End of Forwarded Message From Kustaa.Nyholm at planmeca.com Fri Apr 17 06:01:15 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 17 Apr 2009 15:01:15 +0300 Subject: [Rxtx] rxtx list configuration... Message-ID: Trent, Would it be possible to configure the mail headers for mail that comes from the list so that the 'from' field would be 'rxtx at qbang.org' and not the posters email address? That would save me a couple of clicks each time I reply (now I need to 'reply to all' and delete the other recipients) and a few mistakes (when I hit the 'reply to sender'). Just did that mistake twice in a row, my apologies for those concerned. Just a wish. br Kusti From ilkka at myller.com Fri Apr 17 06:17:14 2009 From: ilkka at myller.com (Ilkka Myller) Date: Fri, 17 Apr 2009 15:17:14 +0300 Subject: [Rxtx] Java5 support In-Reply-To: References: Message-ID: <934E311F-9FCC-4EF2-A1D5-960285363221@myller.com> I completely agree with Kustaa on this one. Our company is developing devices with embedded hardware. We are using RS-232 (and other serial interfaces) with both old and new designs. Serial interfaces are convenient/practical with embedded low cost microprocessors etc. where hardware/software overhead and complexity of more "modern" interfaces is just .. well.. overhead. So, in my opinion, RS-232 (and others) are not obsolete or legacy - at least in industrial/embedded development. It is true, that there are little or no new consumer devices with RS-232 interfaces. -- I >> From: Paul Cunningham >> [snip] in a world where RS-232 is only used for legacy support of >> devices >> with no hope for firmware updates. > > This is not entirely true. I mean there is a lot more to RS-232 than > 'legacy > support of devices with no hope for firmware updates'. > > The alternatives to RS-232 (USB comes to mind) are not that > attractive to > many niche device / system manufactures because implementing them and > supporting them, especially across many platforms is often beyond > their > means and capabilities. Hence even new designs are based on RS232 on > way > or the other. > > RS232 is about the only easy(ish) way to access the outside world > from in a > relatively device and platform independent manor. > > Also even when implementing USB is feasible the other limitation of > USB may > make RS232 much more attractive proposition. Five meter cable length > limitation and the utter unpracticality of implementing galvanic > isolation > come to mind. > > br Kusti > > BTW I did not quite get what the rest of the sentence ('with no hope > for > firmware updates') referred to. > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From cowwoc at bbs.darktech.org Fri Apr 17 06:48:31 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Fri, 17 Apr 2009 08:48:31 -0400 Subject: [Rxtx] Problems with read timeout In-Reply-To: <49E80EEF.6000503@bbs.darktech.org> References: <49E64A4A.1050806@bbs.darktech.org> <49E80EEF.6000503@bbs.darktech.org> Message-ID: <49E87A9F.9070200@bbs.darktech.org> To be clear, I'm not really sure I want write() to block. I just want a way to get a timeout if no data has been read or written in at least X ms (i.e. we're waiting on the remote end) *and* we're blocked on a read() or write() command. It's not clear to me how to achieve this, with or without the new NIO APIs. I'm fairly certain the only way this will work is if flush() blocks until the remote end receives the full message. I'll look into the C code later on tonight to see if this is possible. What are your thoughts on this? Gili cowwoc wrote: > > I've been playing with the read timeout behavior and I'm seeing some > non-intuitive behavior. > > I've got an endless loop that does the following: > > 1) COM1 and COM2 are connected to one another. They are opened at 300 > baud, with read timeout of 300ms. > 2) COM1 writes "CONNECTION" > 3) COM2 reads "CONNECTION" > 4) COM2 writes "CONNECTION 9600 8 NONE 1 RTS/CTS" and tries a read > operation. > 5) COM1 receives "CONNECTION 960" when suddenly COM2 hits the 300ms read > timeout. COM2 gets an IOException (caused by the timeout), and closes > the serial port. > 6) COM1 never gets the full message because the connection was closed in > middle of sending. > > I want step 4 to block until COM1 receives the full message before > it attempts the read operation but I'm not sure how to achieve this. I > was somewhat expecting the write() or flush() operation to block until > the send was complete... Any ideas? > > Gili > From paul at cometway.com Fri Apr 17 08:23:18 2009 From: paul at cometway.com (Paul Cunningham) Date: Fri, 17 Apr 2009 10:23:18 -0400 Subject: [Rxtx] Java5 support In-Reply-To: References: Message-ID: <91A48B92-4A0D-4030-9129-F0657723765B@cometway.com> >> From: Paul Cunningham >> [snip] in a world where RS-232 is only used for legacy support of >> devices >> with no hope for firmware updates. > > This is not entirely true. I mean there is a lot more to RS-232 than > 'legacy > support of devices with no hope for firmware updates'. Hi Kustaa -- Oh I agree with you, mostly. Read my other post. Its just that the money isn't really there to commercially push RS-232 as a mainstream solution anymore. It's difficult these days to find a computer with a DB9 port for doing RS-232 stuff. Anyone still making that kind of hardware is seriously industrial or fringe/hobbyist. On Apr 17, 2009, at 7:54 AM, Kustaa Nyholm wrote: > BTW I did not quite get what the rest of the sentence ('with no hope > for > firmware updates') referred to. Hobbyists are always interested in finding new uses for uniquely functional serial devices that are no longer made, supported, and/or documented. While reverse engineering can be fun, sometimes bad serial driver code and protocol anomalies make it less than straight-forward to implement a reliable interface, and it's not because RXTX isn't working correctly. I have a cool little device that we use to monitor the temperature of our server room using RXTX, but the code I had to write to get it working was less than conventional. -pc -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090417/61103c37/attachment.html From tjarvi at qbang.org Fri Apr 17 08:34:13 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 17 Apr 2009 08:34:13 -0600 (MDT) Subject: [Rxtx] Problems with read timeout In-Reply-To: <49E87A9F.9070200@bbs.darktech.org> References: <49E64A4A.1050806@bbs.darktech.org> <49E80EEF.6000503@bbs.darktech.org> <49E87A9F.9070200@bbs.darktech.org> Message-ID: The bytesavailable event can be used to start your read. There is also an outputbufferempty event. On Fri, 17 Apr 2009, cowwoc wrote: > > To be clear, I'm not really sure I want write() to block. I just want a > way to get a timeout if no data has been read or written in at least X > ms (i.e. we're waiting on the remote end) *and* we're blocked on a > read() or write() command. > > It's not clear to me how to achieve this, with or without the new NIO > APIs. I'm fairly certain the only way this will work is if flush() > blocks until the remote end receives the full message. I'll look into > the C code later on tonight to see if this is possible. What are your > thoughts on this? > > Gili > > cowwoc wrote: >> >> I've been playing with the read timeout behavior and I'm seeing some >> non-intuitive behavior. >> >> I've got an endless loop that does the following: >> >> 1) COM1 and COM2 are connected to one another. They are opened at 300 >> baud, with read timeout of 300ms. >> 2) COM1 writes "CONNECTION" >> 3) COM2 reads "CONNECTION" >> 4) COM2 writes "CONNECTION 9600 8 NONE 1 RTS/CTS" and tries a read >> operation. >> 5) COM1 receives "CONNECTION 960" when suddenly COM2 hits the 300ms read >> timeout. COM2 gets an IOException (caused by the timeout), and closes >> the serial port. >> 6) COM1 never gets the full message because the connection was closed in >> middle of sending. >> >> I want step 4 to block until COM1 receives the full message before >> it attempts the read operation but I'm not sure how to achieve this. I >> was somewhat expecting the write() or flush() operation to block until >> the send was complete... Any ideas? >> >> Gili >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Steffen.DETTMER at ingenico.com Fri Apr 17 09:17:51 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 17 Apr 2009 17:17:51 +0200 Subject: [Rxtx] FW: Java5 support In-Reply-To: References: Message-ID: <20090417151751.GD16563@elberon.bln.de.ingenico.com> * Kustaa Nyholm wrote on Fri, Apr 17, 2009 at 14:56 +0300: > > - Some `wrapper' adding usability to the Java APIs (like > > InputStream) IMHO is essential and required anyway. > > > Me for one definitely don't need anywrapper, I'm happy with the way > the API is. javax.comm/gnu.io is a very low level abstraction of > the under laying hardware, and IMO it should stay that way. Well, so it seems it is a matter of opinion (for me, it is neither an abstraction nor low level; actually, InputStream IMHO is a high [too high] level). (I also think it should stay the way as it is, which IMHO is gnu.io not javax.comm) > Anyone interested in a better wrapper is of course free to > implement and publish one, if so inclined. But let's keep this > in perspective, serial port is small, but sometimes crucial, > well established thing that will not get better by braking > things by improving it. Is the SerialPort API a `well established thing'? I would consider it exotic - most people / applications never used it, I guess. > > I dislike the APIs, for instance InputStream and those. It is > > almost impossible to write really correct code with it. It is > > sufficient for simple GUI stuff you can kill if it blocks or > > so, but for e.g. server applications IMHO it is not sufficient. > > Timeouts are needed and so on. > > Would be fascinating to learn more about this as I've never had > any problem with APIs. Does this mean you are using InputStream for communication and you never had any problem with it? Including no timeout related problems appeared? We had and have a lot here. Sometimes timeouts are not precise enough and synchronisation with embedded stuff fails. Issues with serial w/o (hardware/any) flow control and performance. Issues with lower performance because of unprecise polling timeouts. To big timeouts leading to slow systems and to small timeouts to leading to trouble to unwanted repeations or messages where message boundaries depend on timeouts (like X.25 Gateways without ADPU protocols). I think the most troublesome things here are those transparent protocol converters / gateways and the protocols that depend on timeouts (like `100 ms silence for block separation' or `optional CRC within X.25 frame timeout or set more bit' converted to serial line). If you're using some PPP with TCP on top, I guess this wouldn't be critical because TCP cares about timeouts and retransmissions, but on serial links we often have to implement various protocols without such features. I think, with just an InputStream / OutputStream API it would be almost impossible to write a good, stable and performant TCP/IP/PPP stack. > > Well, this would just lead to a API discussion which would be a > > different topic. > > > > Because a wrapper is needed, package namings IMHO are no issue. > > Personally, I would prefer for some future version to drop the > > logical dependency to the stange javax.comm.SerialPort thingy, > > instead have a clean simple but specific JNI interface. > > This is `an implementation detail', so rxtx can do whatever is > > appropriate :) > > > I would suspect that most user would not welcome anything that > brakes compatibility with the existing API. I would not be surprised if more use gnu.io than javax.comm, so also because of this it would be gnu.io that rxtx should be compatible to! (actually this is a guess, maybe someone has some statistics or makes some poll? I vote for gnu.io and would be able to find more inside the company :)) The JNI interface isn't to be used by the applications; they should work on gnu.io.SerialPort and related objects but never directly on all the JNI functions. >> timeouts, so they must use e.g. SerialPort and now all >> abstraction is gone, because timeouts for a SerialPort and >> SocketChannel are completely different in Java (unlike >> select(), which does abstract). >> > I'm not sure I followed/understood everything above but it > smelt like *one* POV and I suspect, that if I had understood > what I read, that I would have had a different POV. yeah, maybe... (but maybe BSD socket API style is just strong and InputStream API style is just weak - and that recent Java APIs come closer to BSD socket API style IMHO could be an indication that others agree). >> So I think the `break' from javax.comm should be no issue. > Depending on what above means this could be huge issues for > many of us. But I think I've said that several times already. well, I thought almost noone is still using javax.comm, thought only gnu.io was maintained and bugfixed since quite some time (years) - even if technically it is implemented in a branch 0.1.0. This branch IMHO is also an implementation detail; I think (not sure, of course I can be wrong, let's ask Trent and the team). I think rxtx users should not care from which branch a release is built. > > When high performance is an issue, I think it would be required > > that on the JNI interface multiple ports can be processed with > > a single thread and a single call, for instance if data is > > buffered per port and the single call processes all active > > ports or so. In such a case I think it would be likely that a > > kind of BSD socket API interface would result as internal JNI > > interface, but this also is another topic. > > > This paragraph had so many assumptions that I refrain from > commenting other than that it portrays one POV which again I > suspect I do not care for. An alternative, which could be more helpful than refraining from commenting :-), could be to add other high performance setups that could exist on PCs (or where rxtx is running one). anyway, we agree that no ultra high performance requirements exist (probably). I admit that I accidently focussed on UART style hardware for 115kbaud or so, where one port is easy to handle. Yes, of course you are right, there could be a high performance requirement even for setups with few ports, even with a single one. Do you have an example of it which is not very specific (and thus wants to use rxtx)? IMHO it does not help much to talk about specific special serial power hardware which may even require to be accessed with specific driver APIs, because this is out of scope of rxtx :-) oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Steffen.DETTMER at ingenico.com Fri Apr 17 09:40:07 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 17 Apr 2009 17:40:07 +0200 Subject: [Rxtx] Java5 support In-Reply-To: <91A48B92-4A0D-4030-9129-F0657723765B@cometway.com> References: <91A48B92-4A0D-4030-9129-F0657723765B@cometway.com> Message-ID: <20090417154006.GE16563@elberon.bln.de.ingenico.com> * Paul Cunningham wrote on Fri, Apr 17, 2009 at 10:23 -0400: > > This is not entirely true. I mean there is a lot more to > > RS-232 than 'legacy support of devices with no hope for > > firmware updates'. > > Hi Kustaa -- Oh I agree with you, mostly. Read my other post. > Its just that the money isn't really there to commercially > push RS-232 as a mainstream solution anymore. this depends where you look. On a rxtx mailing list, RS-232 surely is mainstream - guess everyone here is using it :-) Network routers usually still have a serial console and embedded board often have one (which probably counts as industrial). > It's difficult these days to find a computer with a DB9 port > for doing RS-232 stuff. Anyone still making that kind of > hardware is seriously industrial or fringe/hobbyist. Yes, consumer devices are rarely with RS232 now, but have USB (or bluetooth). But on PC, you usually can plug some PCMCIA / PCI card or a USB interface to connect, which sometimes also have their issues... Maybe would be interesting to see what people are using rxtx and RS232 here for? The temperature monitor is nice :) I could imagine a few other similar things people use here (connecting to some small controller/sensor board or so). We use it to communicate with various embedded devices, cash registers, small serial printers and communication means like modems and pads (mostly in C but some in Java). oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Steffen.DETTMER at ingenico.com Fri Apr 17 09:51:56 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 17 Apr 2009 17:51:56 +0200 Subject: [Rxtx] rxtx list configuration... In-Reply-To: References: Message-ID: <20090417155156.GF16563@elberon.bln.de.ingenico.com> [OT] * Kustaa Nyholm wrote on Fri, Apr 17, 2009 at 15:01 +0300: > Would it be possible to configure the mail headers for mail > that comes from the list so that the 'from' field would be > 'rxtx at qbang.org' and not the posters email address? Please don't rewrite the `From:' field, because then it would not visible who wrote a posting and it would violate standards potentionally leading to all sort of problems. > That would save me a couple of clicks each time I reply (now I > need to 'reply to all' and delete the other recipients) and a > few mistakes (when I hit the 'reply to sender'). There are mail programs (MUAs) and Plug-Ins for others that handle this automatically. > Just did that mistake twice in a row, my apologies for those concerned. no problem (other way around would be bad :)). oki, Steffen BTW: http://www.unicom.com/pw/reply-to-harmful.html http://woozle.org/~neale/papers/reply-to-still-harmful.html> About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Steffen.DETTMER at ingenico.com Fri Apr 17 09:54:50 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 17 Apr 2009 17:54:50 +0200 Subject: [Rxtx] Java5 support In-Reply-To: <20090417154006.GE16563@elberon.bln.de.ingenico.com> References: <91A48B92-4A0D-4030-9129-F0657723765B@cometway.com> <20090417154006.GE16563@elberon.bln.de.ingenico.com> Message-ID: <20090417155450.GG16563@elberon.bln.de.ingenico.com> * Steffen Dettmer wrote on Fri, Apr 17, 2009 at 17:40 +0200: > Maybe would be interesting to see what people are using rxtx and > RS232 here for? http://rxtx.qbang.org/wiki/index.php/Projects is impressing. oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From bschlining at gmail.com Fri Apr 17 10:25:52 2009 From: bschlining at gmail.com (Brian Schlining) Date: Fri, 17 Apr 2009 09:25:52 -0700 Subject: [Rxtx] Java5 support In-Reply-To: <20090417154006.GE16563@elberon.bln.de.ingenico.com> References: <91A48B92-4A0D-4030-9129-F0657723765B@cometway.com> <20090417154006.GE16563@elberon.bln.de.ingenico.com> Message-ID: > > Maybe would be interesting to see what people are using rxtx and > RS232 here for? The vast majority of oceanographic instruments that we work with have serial connectors. These include acoustic doppler current profilers (ADCP), conductivity-temperature-depth sensors (CTD), radiometers, oxygen sensors, and meteorology sensors. We also use pro-grade VCR's that have serial ports on them for control. We use RXTX on a range of JVM's from J9 through the latest Sun JVM. A particularly cool project that we use RXTX for is SIAM ( http://www.mbari.org/moos/siam/siam.htm). Especially note the PUCK protocol (http://www.mbari.org/pw/puck.htm). Essentially, we create instruments with a little blob of Java code embedded with it as the instrument driver. When the instrument gets plugged in the host controller grabs the driver off and starts running it. Voila, plug-and-work instruments (almost always controlled via a serial port using RXTX) -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090417/f92c3bf8/attachment.html From cowwoc at bbs.darktech.org Fri Apr 17 10:50:15 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Fri, 17 Apr 2009 12:50:15 -0400 Subject: [Rxtx] Java5 support In-Reply-To: <20090417095501.GL13774@elberon.bln.de.ingenico.com> References: <91BF244D-07E4-4B30-9F9D-0DC0964045B4@cometway.com> <49E7900D.3060100@bbs.darktech.org> <20090417095501.GL13774@elberon.bln.de.ingenico.com> Message-ID: <49E8B347.9010609@bbs.darktech.org> I wanted to address two points that have been brought up: > New development doesn't use RS-232. Actually, I've seen quite a few devices using RS-232 over USB. > InputStream isn't appropriate for RS-232 because of timeouts. This is addressed by java.nio.Channels. Gili From greg.johnson at rbr-global.com Fri Apr 17 10:51:44 2009 From: greg.johnson at rbr-global.com (Greg Johnson) Date: Fri, 17 Apr 2009 12:51:44 -0400 Subject: [Rxtx] Java5 support In-Reply-To: References: <91A48B92-4A0D-4030-9129-F0657723765B@cometway.com> <20090417154006.GE16563@elberon.bln.de.ingenico.com> Message-ID: <42447237-7898-470E-835B-A09A6119458F@rbr-global.com> And we make some of those oceanographic instruments - and we use RXTX to configure and download data from them... We run our code on win32/ osx/linux (x86) and the Aonix Perc Ultra JVM (arm). (Brian, please say hi to Tom O'R. for me - I didn't realise mbari was represented on this list :) Cheers, greg -- Greg Johnson, PhD Director of Engineering http://www.rbr-global.com greg.johnson at rbr-global.com +1.613.233.1621 (GMT-5) office +1.613.986.1621 (GMT-5) mobile See us at: Oceans '09 IEEE, Bremen, Germany, May 11 - 14, 2009 On 17-Apr-09, at 12:25 , Brian Schlining wrote: > Maybe would be interesting to see what people are using rxtx and > RS232 here for? > > The vast majority of oceanographic instruments that we work with > have serial connectors. These include acoustic doppler current > profilers (ADCP), conductivity-temperature-depth sensors (CTD), > radiometers, oxygen sensors, and meteorology sensors. We also use > pro-grade VCR's that have serial ports on them for control. We use > RXTX on a range of JVM's from J9 through the latest Sun JVM. > > A particularly cool project that we use RXTX for is SIAM (http://www.mbari.org/moos/siam/siam.htm > ). Especially note the PUCK protocol (http://www.mbari.org/pw/ > puck.htm). Essentially, we create instruments with a little blob of > Java code embedded with it as the instrument driver. When the > instrument gets plugged in the host controller grabs the driver off > and starts running it. Voila, plug-and-work instruments (almost > always controlled via a serial port using RXTX) > > -- > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > Brian Schlining > bschlining at gmail.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090417/d2048c45/attachment.html From tjarvi at qbang.org Fri Apr 17 11:16:45 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 17 Apr 2009 11:16:45 -0600 (MDT) Subject: [Rxtx] Java5 support In-Reply-To: <42447237-7898-470E-835B-A09A6119458F@rbr-global.com> References: <91A48B92-4A0D-4030-9129-F0657723765B@cometway.com> <20090417154006.GE16563@elberon.bln.de.ingenico.com> <42447237-7898-470E-835B-A09A6119458F@rbr-global.com> Message-ID: Disclosure on my part. rxtx is used in the base MATLAB product with an estimated 4 million usrs. http://www.informaworld.com/smpp/title~content=t795248263~db=all http://www.mathworks.com/products/instrument/supportedio13781.html We see some funky projects :) USB serial dongle drivers improving over the last few years has actually boosted the popluarity of serial use. On Fri, 17 Apr 2009, Greg Johnson wrote: > And we make some of those oceanographic instruments - and we use RXTX to > configure and download data from them... ?We run our code on win32/osx/linux > (x86) and the Aonix Perc Ultra JVM (arm). > (Brian, please say hi to Tom O'R. for me - I didn't realise mbari was > represented on this list :) > > Cheers, > > greg > > -- > Greg Johnson, PhD > Director of Engineering > http://www.rbr-global.com > greg.johnson at rbr-global.com > +1.613.233.1621 (GMT-5) office > +1.613.986.1621 (GMT-5) mobile > > See us at: Oceans '09 IEEE, Bremen, Germany, ?May 11 - 14, 2009 > > > On 17-Apr-09, at 12:25 , Brian Schlining wrote: > > Maybe would be interesting to see what people are > using rxtx and > RS232 here for? > > > The vast majority of?oceanographic?instruments that we work with have > serial connectors. These include acoustic doppler current profilers > (ADCP), conductivity-temperature-depth sensors (CTD), radiometers, > oxygen sensors, and?meteorology?sensors. We also use pro-grade VCR's > that have serial ports on them for control. We use RXTX on a range of > JVM's from J9 through the latest Sun JVM. > > A particularly cool project that we use RXTX for is SIAM > (http://www.mbari.org/moos/siam/siam.htm). Especially note the PUCK > protocol (http://www.mbari.org/pw/puck.htm).?Essentially, we create > instruments with a little blob of Java code embedded with it as the > instrument driver. When the instrument gets plugged in the host > controller grabs the driver off and starts running it. Voila, > plug-and-work instruments (almost always controlled via a serial port > using RXTX) > > -- > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > Brian Schlining > bschlining at gmail.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > From Bob_Jacobsen at lbl.gov Fri Apr 17 18:19:16 2009 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Fri, 17 Apr 2009 17:19:16 -0700 Subject: [Rxtx] Java5 support In-Reply-To: <20090417155450.GG16563@elberon.bln.de.ingenico.com> References: <91A48B92-4A0D-4030-9129-F0657723765B@cometway.com> <20090417154006.GE16563@elberon.bln.de.ingenico.com> <20090417155450.GG16563@elberon.bln.de.ingenico.com> Message-ID: RXTX is not just RS232. A _lot_ of USB equipment provide a serial-port-like interface, e.g. via virtual com port drivers. For a device manufacturer, dropping an FTDI or SiLabs chip into their device to provide a computer interface solves a lot of problems. The chips come with drivers for N varients of Windows, Linux, Mac, etc, so the device manufacturer doesn't have to deal with the computer access issues at all. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From scldad at sdc.com.au Fri Apr 17 19:22:04 2009 From: scldad at sdc.com.au (Stephen Davies) Date: Sat, 18 Apr 2009 10:52:04 +0930 Subject: [Rxtx] Java5 support In-Reply-To: <20090417154006.GE16563@elberon.bln.de.ingenico.com> References: <91A48B92-4A0D-4030-9129-F0657723765B@cometway.com> <20090417154006.GE16563@elberon.bln.de.ingenico.com> Message-ID: <200904181052.04460.scldad@sdc.com.au> We use rxtx to interface to a wide variety of remote sensors located in paddocks around the country. The sensors and controlling loggers are manufactured by Campbell Scientific and the loggers have "real" RS232 interfaces. Cheers, Stephen On Saturday 18 April 2009 01:10:07 Steffen DETTMER wrote: > Maybe would be interesting to see what people are using rxtx and > RS232 here for? -- ============================================================================= Stephen Davies Consulting P/L Voice: 08-8177 1595 Adelaide, South Australia. Fax : 08-8177 0133 Computing & Network solutions. Mobile:040 304 0583 VoIP:sip:1132210 at sip1.bbpglobal.com From cowwoc at bbs.darktech.org Wed Apr 1 22:05:13 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Thu, 02 Apr 2009 00:05:13 -0400 Subject: [Rxtx] Windows 64-bit support? Message-ID: <49D43979.4050702@bbs.darktech.org> Hi, I'd like to run RXTX under the Windows 64-bit JVM. Are there plans to release an official 64-bit version anytime soon? Gili From bill7007 at gmail.com Thu Apr 2 16:01:17 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Thu, 2 Apr 2009 18:01:17 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel Message-ID: Hi, I have an rxtx serial application that used to work reliably until I had to move it to newer hardware and kernel. Now, the application sometimes hangs near first port use. When it does hang, it can be released by starting a second copy of the application which is locked out of the ports but does release the first process. Upgraded from rxtx-2.1-7-r2 to rxtx-2.2pre2 but still hangs. Tried to rebuild on the target machine and ran into the 'UTS_RELEASE' undeclared problem so holding on that approach. Recompiled OK on a 2.6.9-42.0.3.ELsmp system. Debug messages were turned on using: "./configure --enable-DEBUG" and modified RXTXPort.java with: "debug = true;" "z = new Zystem(Zystem.PRINT_MODE);" Below is capture of the application with debugging enabled. It show the application hang point, and the second application's printout at the release point. (pre3 is the locally modified version of pre2) Any suggestions on how to pin this down further? Thanks, +BillJ $ java -version java version "1.5.0_06" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05) Java HotSpot(TM) Client VM (build 1.5.0_06-b05, mixed mode, sharing) $ uname -a Linux qms4 2.6.18-92.1.6.el5 #1 SMP Wed Jun 25 13:49:24 EDT 2008 i686 i686 i386 GNU/Linux ***CAPTURE: [qms at qms4 ~]$ ./qms/ScriptFiles/startup.sh Thu Apr 02 13:35:45 EDT 2009:Setting Log File to:/home/qms/qms/QMS.log Thu Apr 02 13:35:45 EDT 2009:TSettings.HandleIni:ReUsing Ini file:/home/qms/qms/qms.properties WARNING: RXTX Version mismatch Jar version = RXTX-2.2pre2 native lib Version = RXTX-2.2pre3 fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB2 fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB1 fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB0 fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile RXTXPort {} RXTX WARNING: This library was compiled to run with OS release 2.4.20 and you are currently running OS release 2.6.18-92.1.6.el5. In some cases this can be a problem. Try recompiling RXTX if you notice strange behavior. If you just compiled RXTX make sure /usr/include/linux is a symbolic link to the include files that came with the kernel source and not an older copy. press enter to continue RXTXPort:RXTXPort(/dev/ttyUSB2) called fhs_lock: creating lockfile: 10127 open: locking worked for /dev/ttyUSB2 open: fd returned is 8 RXTXPort:MontitorThread:MonitorThread() RXTXPort:MontitorThread:run() has_line_status_register_acess: Port does not support TIOCSERGETLSR init_threads: get eis init_threads: set eis init_threads: stop RXTXPort:RXTXPort(/dev/ttyUSB2) returns with fd = 8 RXTXPort:setSerialPortParams(38400 8 1 0) called RXTXPort:setSerialPortParams(38400 8 1 0) returning RXTXPort:getInputStream() called and returning Thu Apr 02 13:36:02 EDT 2009:TSerial[22]:Using Port:/dev/ttyUSB2 RXTXPort:getOutputStream() called and returning Thu Apr 02 13:36:02 EDT 2009:TSerial[22].Transmit:TN Entering RXTXPort:SerialOutputStream:write(4) writeArray() Leaving RXTXPort:SerialOutputStream:write(4) RXTXPort:SerialOutputStream:flush() enter RXTXPort:SerialOutputStream:flush() leave Thu Apr 02 13:36:02 EDT 2009:TSerial[22].Transmit:RV Entering RXTXPort:SerialOutputStream:write(4) writeArray() Leaving RXTXPort:SerialOutputStream:write(4) RXTXPort:SerialOutputStream:flush() enter RXTXPort:SerialInputStream:read(8192 0 8192) called ***FIRST PROCESS HANGS HERE ***THEN PROCEEDS AFTER SECOND PROCESS STARTS RXTXPort:SerialOutputStream:flush() leave Thu Apr 02 13:41:29 EDT 2009:TSerial[22].Transmit:IH9 Entering RXTXPort:SerialOutputStream:write(5) writeArray() Leaving RXTXPort:SerialOutputStream:write(5) RXTXPort:SerialOutputStream:flush() enter RXTXPort:SerialOutputStream:flush() leave Thu Apr 02 13:41:29 EDT 2009:TSerial[22].Transmit:IL11 ***END CAPTURE ***CAPTURE SECOND PROCESS FAILS OPEN [qms at qms4 ~]$ ./qms/ScriptFiles/startup.sh Thu Apr 02 13:41:27 EDT 2009:Setting Log File to:/home/qms/qms/QMS.log Thu Apr 02 13:41:27 EDT 2009:TSettings.HandleIni:ReUsing Ini file:/home/qms/qms/qms.properties WARNING: RXTX Version mismatch Jar version = RXTX-2.2pre2 native lib Version = RXTX-2.2pre3 fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB2: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB1: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB0: File exists fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB2: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB1: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB0: File exists fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile Thu Apr 02 13:41:30 EDT 2009:TIOBoard: java.io.IOException: java.io.IOException: TSerial[22]: Open Failed ***END CAPTURE -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090402/c66f8d70/attachment-0017.html From netbeans at gatworks.com Thu Apr 2 17:15:04 2009 From: netbeans at gatworks.com (U. George) Date: Thu, 02 Apr 2009 19:15:04 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: Message-ID: <49D546F8.20807@gatworks.com> > "z = new Zystem(Zystem.PRINT_MODE);" > Below is capture of the application with debugging enabled. It show > the application hang point, and the second application's printout at the > release point. (pre3 is the locally modified version of pre2) > Any suggestions on how to pin this down further? > Thanks, > +BillJ When perceived runability is hung, try a ^\ ( control \) on console. This gets the JVM to dump the stacks of all the java threads. If you know the thread that is stuck, then u can see what java statement its stuck at. From tjarvi at qbang.org Thu Apr 2 19:25:17 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 2 Apr 2009 19:25:17 -0600 (MDT) Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: <49D546F8.20807@gatworks.com> References: <49D546F8.20807@gatworks.com> Message-ID: On Thu, 2 Apr 2009, U. George wrote: >> "z = new Zystem(Zystem.PRINT_MODE);" >> Below is capture of the application with debugging enabled. It show >> the application hang point, and the second application's printout at the >> release point. (pre3 is the locally modified version of pre2) >> Any suggestions on how to pin this down further? >> Thanks, >> +BillJ > > When perceived runability is hung, try a ^\ ( control \) on console. > This gets the JVM to dump the stacks of all the java threads. > If you know the thread that is stuck, then u can see what java statement > its stuck at. I've also noticed some linux systems hanging with open/read/write and saw kacpid storms. I need to look at it more but did observe kacpid consuming a core and not returning to a normal state for a significant period of time. It was easy to observe from top sorted by CPU usage. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Apr 2 19:26:18 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 2 Apr 2009 19:26:18 -0600 (MDT) Subject: [Rxtx] Windows 64-bit support? In-Reply-To: <49D43979.4050702@bbs.darktech.org> References: <49D43979.4050702@bbs.darktech.org> Message-ID: On Thu, 2 Apr 2009, cowwoc wrote: > Hi, > > I'd like to run RXTX under the Windows 64-bit JVM. Are there plans > to release an official 64-bit version anytime soon? > It is in the prerelease and will be in the final release. I'm pushing it through as fast as I can in my free time. -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Thu Apr 2 22:57:34 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Fri, 03 Apr 2009 00:57:34 -0400 Subject: [Rxtx] Missing documentation In-Reply-To: References: <49D43979.4050702@bbs.darktech.org> Message-ID: <49D5973E.4050400@bbs.darktech.org> Hi, I noticed that RXTX 2.1 drops javax.comm support in favor of gnu.io. I have one major problem with this: the gui.io.* documentation is very poor. Many classes and methods have no Javadoc at all which makes them difficult to use. Please fix this for the final release. Thank you, Gili From alex.sas at freemail.hu Fri Apr 3 01:36:54 2009 From: alex.sas at freemail.hu (Sas Alex) Date: Fri, 3 Apr 2009 09:36:54 +0200 (CEST) Subject: [Rxtx] Serial port false reads Message-ID: Hi all, On Windows XP, using rxtx-2.1-7-r2 I have a program communicating on a serial line like the following (excerpt): { os.write(command); os.flush(); // Thread.sleep(period); // read response while(is.available() > 0) { is.read() } } If there is a sleep between the os.flush and the reading cycle the correct answer is received. Otherwise (sometimes) there are extra, erronous characters at the beginning of the answer, but the correct answer (according to the protocol) also arrives, afterwards. Is this a normal behaviour, one should wait before the read? If yes, is there a way to determine the minimum amount of time to wait for? Serial port params are: 9600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE. Thank you in advance, Alex ________________________________________________________ El?foglal?si akci? meghosszabb?tva! Korfui ?d?l?s m?r 56.910 Ft-t?l. http://www.budavartours.hu/gorogorszag/?utm_campaign=origo&utm_source=freemail_kimeno_090403&utm_medium=ct&utm_content=korfu_elofoglalasi_akcio#reg_Korfu -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090403/8f3650ea/attachment-0017.html From bill7007 at gmail.com Fri Apr 3 16:15:30 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Fri, 3 Apr 2009 18:15:30 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: <49D546F8.20807@gatworks.com> Message-ID: > When perceived runability is hung, try a ^\ ( control \) on console. >> This gets the JVM to dump the stacks of all the java threads. > > Good idea... A thread dump is below, it looks like only some system threads are in wait state which is probably normal. The "main" thread is stopped writing the first data out the serial port which should complete but its has stopped at: at gnu.io.RXTXPort.nativeDrain(Native Method) It show its state as runnable though. There is another thread, "SerialReader_22", that is waiting to read any data on the same port. I'll bring the app up under Netbeans debugger next. >> > I've also noticed some linux systems hanging with open/read/write and saw > kacpid storms. No CPU use going when it hangs, acts like a deadlock. THREAD DUMP AT HANG: Entering RXTXPort:SerialOutputStream:write(4) writeArray() Leaving RXTXPort:SerialOutputStream:write(4) RXTXPort:SerialOutputStream:flush() enter RXTXPort:SerialInputStream:read(8192 0 8192) called Full thread dump Java HotSpot(TM) Client VM (1.5.0_06-b05 mixed mode, sharing): "SerialReader_22" daemon prio=1 tid=0x087abf38 nid=0x3c8b runnable [0xb1a43000..0xb1a43f30] at gnu.io.RXTXPort.readArray(Native Method) at gnu.io.RXTXPort$SerialInputStream.read(RXTXPort.java:1454) - locked <0x88ca55b8> (a gnu.io.RXTXPort$SerialInputStream) at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:411) at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) - locked <0x88cab378> (a java.io.InputStreamReader) at java.io.InputStreamReader.read(InputStreamReader.java:167) at java.io.BufferedReader.fill(BufferedReader.java:136) at java.io.BufferedReader.readLine(BufferedReader.java:299) - locked <0x88cab378> (a java.io.InputStreamReader) at java.io.BufferedReader.readLine(BufferedReader.java:362) at qms.TSerialPort$SerialRead.run(TSerialPort.java:268) at java.lang.Thread.run(Thread.java:595) "Thread-1" prio=1 tid=0x08a43360 nid=0x3c8a runnable [0xb1ac4000..0xb1ac4db0] at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1641) "AWT-XAWT" daemon prio=1 tid=0x08acc848 nid=0x3c87 runnable [0xb1b45000..0xb1b45e30] at sun.awt.X11.XToolkit.waitForEvents(Native Method) at sun.awt.X11.XToolkit.run(XToolkit.java:463) at sun.awt.X11.XToolkit.run(XToolkit.java:438) at java.lang.Thread.run(Thread.java:595) "Java2D Disposer" daemon prio=1 tid=0x08ab9d30 nid=0x3c86 in Object.wait() [0xb1bc6000..0xb1bc70b0] at java.lang.Object.wait(Native Method) - waiting on <0x8917b110> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:116) - locked <0x8917b110> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:132) at sun.java2d.Disposer.run(Disposer.java:107) at java.lang.Thread.run(Thread.java:595) "Low Memory Detector" daemon prio=1 tid=0x087bea68 nid=0x3c84 runnable [0x00000000..0x00000000] "CompilerThread0" daemon prio=1 tid=0x087bd4c0 nid=0x3c83 waiting on condition [0x00000000..0xb23a7a18] "Signal Dispatcher" daemon prio=1 tid=0x087bc520 nid=0x3c82 runnable [0x00000000..0x00000000] "Finalizer" daemon prio=1 tid=0x087b5710 nid=0x3c81 in Object.wait() [0xb26a9000..0xb26a9f30] at java.lang.Object.wait(Native Method) - waiting on <0x8914a770> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:116) - locked <0x8914a770> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:132) at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159) "Reference Handler" daemon prio=1 tid=0x087b49c8 nid=0x3c80 in Object.wait() [0xb272a000..0xb272adb0] at java.lang.Object.wait(Native Method) - waiting on <0x8914a7f0> (a java.lang.ref.Reference$Lock) at java.lang.Object.wait(Object.java:474) at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116) - locked <0x8914a7f0> (a java.lang.ref.Reference$Lock) "main" prio=1 tid=0x08777b88 nid=0x3c7e runnable [0xbffa7000..0xbffa74f8] at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1248) at qms.TSerialPort.Transmit(TSerialPort.java:192) - locked <0x88c99a68> (a qms.TSerialPort) at qms.TIOBoard.GetIOBoardVersion(TIOBoard.java:168) at qms.TIOBoard.(TIOBoard.java:73) at qms.TQMS.(TQMS.java:47) at qms.MainForm.(MainForm.java:2076) at qms.MainForm.main(MainForm.java:2099) "VM Thread" prio=1 tid=0x087b1e20 nid=0x3c7f runnable "VM Periodic Task Thread" prio=1 tid=0x087bff50 nid=0x3c85 waiting on condition -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090403/20b7bca4/attachment-0016.html From Martin.Oberhuber at windriver.com Fri Apr 3 16:23:43 2009 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Sat, 4 Apr 2009 00:23:43 +0200 Subject: [Rxtx] Missing documentation In-Reply-To: <49D5973E.4050400@bbs.darktech.org> References: <49D43979.4050702@bbs.darktech.org> <49D5973E.4050400@bbs.darktech.org> Message-ID: <460801A4097E3D4CA04CC64EE648584809C8BD6F@ism-mail03.corp.ad.wrs.com> Hello Gili, The classes in the gnu.io namespace are designed to work exactly as their counterparts in the javax.comm namespace. Therefore, if you just take the javax.comm Javadocs that's what you want. Unfortunately I don't think we can just copy & paste the javax.comm Javadocs into RXTX due to license restrictions. I guess that's the main reason why RXTX is not (yet) Javadoc'd as extensively as it should be. Actually, writing Javadocs from scratch WITHOUT referencing the wording of the Sun Javadocs is not that easy. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of cowwoc > Sent: Freitag, 03. April 2009 06:58 > To: rxtx at qbang.org > Subject: [Rxtx] Missing documentation > > Hi, > > I noticed that RXTX 2.1 drops javax.comm support in favor > of gnu.io. > I have one major problem with this: the gui.io.* > documentation is very > poor. Many classes and methods have no Javadoc at all which > makes them > difficult to use. Please fix this for the final release. > > Thank you, > Gili > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Fri Apr 3 16:54:50 2009 From: netbeans at gatworks.com (U. George) Date: Fri, 03 Apr 2009 18:54:50 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: <49D546F8.20807@gatworks.com> Message-ID: <49D693BA.8060909@gatworks.com> I would have tried 2 or 3 "^\" . If things are stuck, then all will be at same 'java' instruction. If thread is moving, then one of the snapshots would be different. I *think* flushing/draining wont return until the kernel buffers to device have been accepted by device. Stuck/paused device? Bill Johnson wrote: > > > > > When perceived runability is hung, try a ^\ ( control \) on console. > This gets the JVM to dump the stacks of all the java threads. > > > Good idea... A thread dump is below, it looks like only some system > threads are in wait state which is prob From cowwoc at bbs.darktech.org Fri Apr 3 17:45:09 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Fri, 03 Apr 2009 19:45:09 -0400 Subject: [Rxtx] Missing documentation In-Reply-To: <460801A4097E3D4CA04CC64EE648584809C8BD6F@ism-mail03.corp.ad.wrs.com> References: <49D43979.4050702@bbs.darktech.org> <49D5973E.4050400@bbs.darktech.org> <460801A4097E3D4CA04CC64EE648584809C8BD6F@ism-mail03.corp.ad.wrs.com> Message-ID: <49D69F85.3030804@bbs.darktech.org> You could always send Sun a formal email and ask for permission to copy their Javadoc. I doubt they would give you problems. Gili Oberhuber, Martin wrote: > Hello Gili, > > The classes in the gnu.io namespace are designed to work exactly > as their counterparts in the javax.comm namespace. Therefore, > if you just take the javax.comm Javadocs that's what you want. > > Unfortunately I don't think we can just copy & paste the > javax.comm Javadocs into RXTX due to license restrictions. > > I guess that's the main reason why RXTX is not (yet) Javadoc'd > as extensively as it should be. Actually, writing Javadocs > from scratch WITHOUT referencing the wording of the Sun > Javadocs is not that easy. > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] >> On Behalf Of cowwoc >> Sent: Freitag, 03. April 2009 06:58 >> To: rxtx at qbang.org >> Subject: [Rxtx] Missing documentation >> >> Hi, >> >> I noticed that RXTX 2.1 drops javax.comm support in favor >> of gnu.io. >> I have one major problem with this: the gui.io.* >> documentation is very >> poor. Many classes and methods have no Javadoc at all which >> makes them >> difficult to use. Please fix this for the final release. >> >> Thank you, >> Gili >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> From cowwoc at bbs.darktech.org Sat Apr 4 15:13:38 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sat, 04 Apr 2009 17:13:38 -0400 Subject: [Rxtx] Java5 support Message-ID: <49D7CD82.1040904@bbs.darktech.org> Now that you dropped javax.comm support, how about improving the API by replacing Enumation by Iterator, int by enum, and using Generics? It would improve the usability of the API. Gili From cowwoc at bbs.darktech.org Sat Apr 4 16:12:13 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sat, 04 Apr 2009 18:12:13 -0400 Subject: [Rxtx] RXTX Version mismatch in 2.2pre2 Message-ID: <49D7DB3D.5040008@bbs.darktech.org> When using RXTX-2.2pre2 I always get the following message: WARNING: RXTX Version mismatch Jar version = RXTX-2.2pre1 native lib Version = RXTX-2.2pre2 I have double checked that I am using the correct Jar file. Is this a known bug in pre2? Gili From tjarvi at qbang.org Sat Apr 4 16:48:53 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Apr 2009 16:48:53 -0600 (MDT) Subject: [Rxtx] RXTX Version mismatch in 2.2pre2 In-Reply-To: <49D7DB3D.5040008@bbs.darktech.org> References: <49D7DB3D.5040008@bbs.darktech.org> Message-ID: > When using RXTX-2.2pre2 I always get the following message: > > WARNING: RXTX Version mismatch > Jar version = RXTX-2.2pre1 > native lib Version = RXTX-2.2pre2 > Yep. You should still be able to test it. -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Sat Apr 4 16:50:43 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sat, 04 Apr 2009 18:50:43 -0400 Subject: [Rxtx] RXTX Version mismatch in 2.2pre2 In-Reply-To: References: <49D7DB3D.5040008@bbs.darktech.org> Message-ID: <49D7E443.9070404@bbs.darktech.org> In other words this is a known bug that will be fixed in the final version? Gili Trent Jarvi wrote: > > >> When using RXTX-2.2pre2 I always get the following message: >> >> WARNING: RXTX Version mismatch >> Jar version = RXTX-2.2pre1 >> native lib Version = RXTX-2.2pre2 >> > > Yep. > > You should still be able to test it. > > -- > Trent Jarvi > tjarvi at qbang.org From cowwoc at bbs.darktech.org Sat Apr 4 16:57:34 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sat, 04 Apr 2009 18:57:34 -0400 Subject: [Rxtx] IOException: Underlying input stream returned zero bytes Message-ID: <49D7E5DE.2050405@bbs.darktech.org> Hi, There seems to be a bug in RXTX 2.2pre2's handling of InputStream timeouts. If you open a serial port without ever invoking enableReceiveTimeout() then invoking InputStream.read() will always return 0 bytes right away. If you wrap the InputStream and invoke BufferedReader.readline() you will get the following exception: java.io.IOException: Underlying input stream returned zero bytes at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:268) [na:1.6.0_14-ea] at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:306) [na:1.6.0_14-ea] at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:158) [na:1.6.0_14-ea] at java.io.InputStreamReader.read(InputStreamReader.java:167) [na:1.6.0_14-ea] at java.io.BufferedReader.fill(BufferedReader.java:136) [na:1.6.0_14-ea] at java.io.BufferedReader.readLine(BufferedReader.java:299) [na:1.6.0_14-ea] at java.io.BufferedReader.readLine(BufferedReader.java:362) [na:1.6.0_14-ea] [snip] If you enable a timeout, the exception will only occur after the timeout expires. In short, it looks like RXTX is using a default timeout of zero (I am expecting it to block forever). It looks like other people have run into this as well: http://forums.sun.com/thread.jspa?threadID=5165346&start=10&tstart=0 Please confirm whether this is a known bug. Thank you, Gili From tjarvi at qbang.org Sat Apr 4 17:27:19 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Apr 2009 17:27:19 -0600 (MDT) Subject: [Rxtx] IOException: Underlying input stream returned zero bytes In-Reply-To: <49D7E5DE.2050405@bbs.darktech.org> References: <49D7E5DE.2050405@bbs.darktech.org> Message-ID: On Sat, 4 Apr 2009, cowwoc wrote: > Hi, > > There seems to be a bug in RXTX 2.2pre2's handling of InputStream > timeouts. If you open a serial port without ever invoking > enableReceiveTimeout() then invoking InputStream.read() will always > return 0 bytes right away. If you wrap the InputStream and invoke > BufferedReader.readline() you will get the following exception: > > java.io.IOException: Underlying input stream returned zero bytes > at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:268) > [na:1.6.0_14-ea] > at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:306) > [na:1.6.0_14-ea] > at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:158) > [na:1.6.0_14-ea] > at java.io.InputStreamReader.read(InputStreamReader.java:167) > [na:1.6.0_14-ea] > at java.io.BufferedReader.fill(BufferedReader.java:136) > [na:1.6.0_14-ea] > at java.io.BufferedReader.readLine(BufferedReader.java:299) > [na:1.6.0_14-ea] > at java.io.BufferedReader.readLine(BufferedReader.java:362) > [na:1.6.0_14-ea] > [snip] > > If you enable a timeout, the exception will only occur after the > timeout expires. In short, it looks like RXTX is using a default timeout > of zero (I am expecting it to block forever). It looks like other people > have run into this as well: > http://forums.sun.com/thread.jspa?threadID=5165346&start=10&tstart=0 > > Please confirm whether this is a known bug. > Hi Gili I've known about it but was not sure if it was a bug or not. It looks like we can treat it as a bug if nio is throwing an exception. Timeout and Thresholds are well documented in javax.comm but I didn't recall seeing defaults. For that reason, I've encouraged people to set the threshold and timeout to what they expect. Another note about InputStream.read(void): I noticed that I don't use that function at all while looking at code coverage results. Keep your eye out for additional issues. -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Sat Apr 4 19:03:29 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sat, 04 Apr 2009 21:03:29 -0400 Subject: [Rxtx] IOException: Underlying input stream returned zero bytes In-Reply-To: References: <49D7E5DE.2050405@bbs.darktech.org> Message-ID: <49D80361.7020801@bbs.darktech.org> Trent Jarvi wrote: > For that reason, I've encouraged people to set the threshold and timeout > to what they expect. It doesn't help. There doesn't seem to be a way to disable the timeout, even if you invoke disableReceiveTimeout() explicitly. Let me know when you put in a fix and I will test it. Thanks, Gili From cowwoc at bbs.darktech.org Sat Apr 4 23:27:25 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 01:27:25 -0400 Subject: [Rxtx] Crash in termios.c:892 Message-ID: <49D8413D.7040105@bbs.darktech.org> I can reproduce a crash in RXTX 2.2 pre2 100% of the time using my application code, but I can't seem to bring it down to a minimal testcase. Here is what I see: - thread begins running - open com1 - close com1 - open com5 - leave com5 open - thread shuts down - repeat the same process in a new thread - crash occurs when trying to open com1. Crash disappears if I close() com5 in the previous thread. The output window contains the following: # # A fatal error has been detected by the Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x05475cf6, pid=6064, tid=5436 # # JRE version: 6.0_14-b04 # Java VM: Java HotSpot(TM) Client VM (14.0-b13 mixed mode, sharing windows-x86 ) # Problematic frame: # C [rxtxSerial.dll+0x5cf6] # # An error report file with more information is saved as: # C:\Users\Gili\Documents\foobar\source\hs_err_pid6064.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp Error 0x5 at ..\src\termios.c(892): Access is denied. # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # Please let me know if the crash dump is enough to track down this bug. Thank you, Gili -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: hs_err_pid6064.log Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20090405/7133a1ce/attachment-0013.pl From cowwoc at bbs.darktech.org Sun Apr 5 00:24:19 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 02:24:19 -0400 Subject: [Rxtx] SerialPort.getName() is wrong Message-ID: <49D84E93.7050606@bbs.darktech.org> Sorry for all these emails but I keep on running into more issues. Here is what I noticed: - CommPortIdentifier.getPortIdentifier("COM5") returns a CommPortIdentifier where getName() == "COM5" - If, however, you invoke CommPortIdentifier.open() you get back a SerialPort where SerialPort.getName() is "//./COM5" I am expecting the name to remain consistent. "//./COM5" looks like an implementation detail and (as far as I can tell) it can't be used as an argument for any API method so it is somewhat useless. If getName() were to return "COM5" I could at least use it to get back the original CommPortIdentifier or compare against "known names" such as "COMx" or "LPTx". What do you think? Gili From tjarvi at qbang.org Sun Apr 5 10:18:42 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Apr 2009 10:18:42 -0600 (MDT) Subject: [Rxtx] SerialPort.getName() is wrong In-Reply-To: <49D84E93.7050606@bbs.darktech.org> References: <49D84E93.7050606@bbs.darktech.org> Message-ID: On Sun, 5 Apr 2009, cowwoc wrote: > > Sorry for all these emails but I keep on running into more issues. > Here is what I noticed: > > - CommPortIdentifier.getPortIdentifier("COM5") returns a > CommPortIdentifier where getName() == "COM5" > - If, however, you invoke CommPortIdentifier.open() you get back a > SerialPort where SerialPort.getName() is "//./COM5" > > I am expecting the name to remain consistent. "//./COM5" looks like > an implementation detail and (as far as I can tell) it can't be used as > an argument for any API method so it is somewhat useless. If getName() > were to return "COM5" I could at least use it to get back the original > CommPortIdentifier or compare against "known names" such as "COMx" or > "LPTx". What do you think? > Sure. If it itches enough you should be able to fix this in RXTXCommDriver.java. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Apr 5 10:27:58 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Apr 2009 10:27:58 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D8413D.7040105@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> Message-ID: On Sun, 5 Apr 2009, cowwoc wrote: > > I can reproduce a crash in RXTX 2.2 pre2 100% of the time using my > application code, but I can't seem to bring it down to a minimal testcase. > Here is what I see: > > - thread begins running > - open com1 > - close com1 > - open com5 > - leave com5 open > - thread shuts down > - repeat the same process in a new thread > - crash occurs when trying to open com1. Crash disappears if I close() com5 > in the previous thread. > > The output window contains the following: > > # > # A fatal error has been detected by the Java Runtime Environment: > # > # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x05475cf6, pid=6064, > tid=5436 > # > # JRE version: 6.0_14-b04 > # Java VM: Java HotSpot(TM) Client VM (14.0-b13 mixed mode, sharing > windows-x86 ) > # Problematic frame: > # C [rxtxSerial.dll+0x5cf6] > # > # An error report file with more information is saved as: > # C:\Users\Gili\Documents\foobar\source\hs_err_pid6064.log > # > # If you would like to submit a bug report, please visit: > # http://java.sun.com/webapps/bugreport/crash.jsp > Error 0x5 at ..\src\termios.c(892): Access is denied. > > > # The crash happened outside the Java Virtual Machine in native code. > # See problematic frame for where to report the bug. > # > > Please let me know if the crash dump is enough to track down this bug. > Hi Gili, You are responsible for cleaning up the serial ports when using threads. That said, if the thread did shut down, finalize should have been called if you are not passing the object around. See RXTXPort.java. protected void finalize() { if (debug) z.reportln( "RXTXPort:finalize()"); if( fd > 0 ) { if (debug) z.reportln( "RXTXPort:calling close()"); close(); } z.finalize(); } The exception is interesting. This is on Vista? Usually it just gives an open error when another process has the port. -- Trent Jarvi tjarvi at mathworks.com From cowwoc at bbs.darktech.org Sun Apr 5 10:35:55 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 12:35:55 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: References: <49D8413D.7040105@bbs.darktech.org> Message-ID: <49D8DDEB.5010908@bbs.darktech.org> Trent Jarvi wrote: > You are responsible for cleaning up the serial ports when using threads. > That said, if the thread did shut down, finalize should have been called > if you are not passing the object around. See RXTXPort.java. > > protected void finalize() > { > if (debug) > z.reportln( "RXTXPort:finalize()"); > if( fd > 0 ) > { > if (debug) > z.reportln( "RXTXPort:calling close()"); > close(); > } > z.finalize(); > } Two points: 1) One should never rely on finalizers because they may never run. 2) RXTX shouldn't cause the entire JVM to crash if I misuse the API. The native code should recover more gracefully. > The exception is interesting. This is on Vista? Usually it just gives > an open error when another process has the port. Yes, this is on Vista 64-bit. I'd really like to see this bug fixed. Is this code compilable under Visual Studio? If so, I can debug the problem on my end and send you a patch. Thanks, Gili From cowwoc at bbs.darktech.org Sun Apr 5 10:36:20 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 12:36:20 -0400 Subject: [Rxtx] SerialPort.getName() is wrong In-Reply-To: References: <49D84E93.7050606@bbs.darktech.org> Message-ID: <49D8DE04.6030306@bbs.darktech.org> Trent Jarvi wrote: >> I am expecting the name to remain consistent. "//./COM5" looks like >> an implementation detail and (as far as I can tell) it can't be used as >> an argument for any API method so it is somewhat useless. If getName() >> were to return "COM5" I could at least use it to get back the original >> CommPortIdentifier or compare against "known names" such as "COMx" or >> "LPTx". What do you think? >> > > Sure. > > If it itches enough you should be able to fix this in RXTXCommDriver.java. I'm not sure I understand. Are you saying that if I submit a patch you will commit it? Gili From tjarvi at qbang.org Sun Apr 5 10:46:23 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Apr 2009 10:46:23 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D8DDEB.5010908@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> Message-ID: On Sun, 5 Apr 2009, cowwoc wrote: > Trent Jarvi wrote: >> You are responsible for cleaning up the serial ports when using threads. >> That said, if the thread did shut down, finalize should have been called if >> you are not passing the object around. See RXTXPort.java. >> >> protected void finalize() >> { >> if (debug) >> z.reportln( "RXTXPort:finalize()"); >> if( fd > 0 ) >> { >> if (debug) >> z.reportln( "RXTXPort:calling close()"); >> close(); >> } >> z.finalize(); >> } > > Two points: > > 1) One should never rely on finalizers because they may never run. > 2) RXTX shouldn't cause the entire JVM to crash if I misuse the API. The > native code should recover more gracefully. > >> The exception is interesting. This is on Vista? Usually it just gives an >> open error when another process has the port. > > Yes, this is on Vista 64-bit. I'd really like to see this bug fixed. > Is this code compilable under Visual Studio? If so, I can debug the problem > on my end and send you a patch. > It will compile with the msvc cl.exe and nmake. See Makefile.msvc in the top level directory. You will need to adjust the JAVA_HOME variable. Also use the MSVC command prompt for x86_64 so cl and nmake are on your path. All the best, -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Apr 5 10:49:10 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Apr 2009 10:49:10 -0600 (MDT) Subject: [Rxtx] SerialPort.getName() is wrong In-Reply-To: <49D8DE04.6030306@bbs.darktech.org> References: <49D84E93.7050606@bbs.darktech.org> <49D8DE04.6030306@bbs.darktech.org> Message-ID: On Sun, 5 Apr 2009, cowwoc wrote: > Trent Jarvi wrote: >>> I am expecting the name to remain consistent. "//./COM5" looks like >>> an implementation detail and (as far as I can tell) it can't be used as >>> an argument for any API method so it is somewhat useless. If getName() >>> were to return "COM5" I could at least use it to get back the original >>> CommPortIdentifier or compare against "known names" such as "COMx" or >>> "LPTx". What do you think? >>> >> >> Sure. >> >> If it itches enough you should be able to fix this in RXTXCommDriver.java. > > I'm not sure I understand. Are you saying that if I submit a patch > you will commit it? > Hi Gili, Post a patch here and if nobody complains, we will commit it and give you credit. Yep. Other issues like changing the API to use java5 that may break existing apps are likely to run into objections but bug fixes usually get fixed just as you mention. -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Sun Apr 5 10:55:07 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 12:55:07 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> Message-ID: <49D8E26B.2040705@bbs.darktech.org> Trent Jarvi wrote: > It will compile with the msvc cl.exe and nmake. See Makefile.msvc in > the top level directory. You will need to adjust the JAVA_HOME > variable. Also use the MSVC command prompt for x86_64 so cl and nmake > are on your path. This is very odd. The CVS version of the code does not contain this file. Do you keep the latest code somewhere else? Gili From cowwoc at bbs.darktech.org Sun Apr 5 11:01:58 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 13:01:58 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D8E26B.2040705@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> Message-ID: <49D8E406.10708@bbs.darktech.org> cowwoc wrote: > Trent Jarvi wrote: >> It will compile with the msvc cl.exe and nmake. See Makefile.msvc in >> the top level directory. You will need to adjust the JAVA_HOME >> variable. Also use the MSVC command prompt for x86_64 so cl and nmake >> are on your path. > > This is very odd. The CVS version of the code does not contain this > file. Do you keep the latest code somewhere else? Okay I figured it out. CVS head is out of date, the "commapi-0-0-1" revision contains the correct files. Gili From tjarvi at qbang.org Sun Apr 5 11:05:43 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Apr 2009 11:05:43 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D8E26B.2040705@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> Message-ID: CVS HEAD is currently the rxtx 2.0 code. A branch was created long ago for 'experimental' gnu.io work. It just happens that the branch is what everyone uses now. checkout -r commapi-0-0-1 rxtx-devel will get the branch On Sun, 5 Apr 2009, cowwoc wrote: > Trent Jarvi wrote: >> It will compile with the msvc cl.exe and nmake. See Makefile.msvc in the >> top level directory. You will need to adjust the JAVA_HOME variable. Also >> use the MSVC command prompt for x86_64 so cl and nmake are on your path. > > This is very odd. The CVS version of the code does not contain this > file. Do you keep the latest code somewhere else? > > Gili > From cowwoc at bbs.darktech.org Sun Apr 5 14:50:47 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 16:50:47 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> Message-ID: <49D919A7.1070806@bbs.darktech.org> Okay, I tracked down the crash. It's being caused by YACK() using a 80-character buffer. The error message is longer than 80 characters, so _snprintf_s() crashes to avoid a buffer overflow. Please apply the attached patch and add the zipped up Visual Studio project directory. It's not perfect yet but it's a good start. Gili Trent Jarvi wrote: > > CVS HEAD is currently the rxtx 2.0 code. A branch was created long > ago for 'experimental' gnu.io work. It just happens that the branch > is what everyone uses now. > > checkout -r commapi-0-0-1 rxtx-devel > > will get the branch > > On Sun, 5 Apr 2009, cowwoc wrote: > >> Trent Jarvi wrote: >>> It will compile with the msvc cl.exe and nmake. See Makefile.msvc >>> in the top level directory. You will need to adjust the JAVA_HOME >>> variable. Also use the MSVC command prompt for x86_64 so cl and >>> nmake are on your path. >> >> This is very odd. The CVS version of the code does not contain >> this file. Do you keep the latest code somewhere else? >> >> Gili >> -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx-devel.patch Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20090405/d9b82962/attachment-0012.pl -------------- next part -------------- A non-text attachment was scrubbed... Name: Win32.zip Type: application/octet-stream Size: 17764 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20090405/d9b82962/attachment-0014.obj From cowwoc at bbs.darktech.org Sun Apr 5 15:22:01 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 17:22:01 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D919A7.1070806@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> <49D919A7.1070806@bbs.darktech.org> Message-ID: <49D920F9.6080702@bbs.darktech.org> My mistake. The problem in YACK is real, but it isn't the real cause of the crash. The crash is caused by termios.c line 1099: index->prev->next = port; because in my case "index->prev==0". I think the bug is that the code assumes that index will contain a minimum of two entries if we're inserting a previously closed fd. In my case, it only contains one. I'm not sure why you have this code branch (as opposed to appending to the end of index). Please take a look. Thanks, Gili cowwoc wrote: > > Okay, I tracked down the crash. It's being caused by YACK() using a > 80-character buffer. The error message is longer than 80 characters, so > _snprintf_s() crashes to avoid a buffer overflow. > > Please apply the attached patch and add the zipped up Visual Studio > project directory. It's not perfect yet but it's a good start. > > Gili > > Trent Jarvi wrote: >> >> CVS HEAD is currently the rxtx 2.0 code. A branch was created long >> ago for 'experimental' gnu.io work. It just happens that the branch >> is what everyone uses now. >> >> checkout -r commapi-0-0-1 rxtx-devel >> >> will get the branch >> >> On Sun, 5 Apr 2009, cowwoc wrote: >> >>> Trent Jarvi wrote: >>>> It will compile with the msvc cl.exe and nmake. See Makefile.msvc >>>> in the top level directory. You will need to adjust the JAVA_HOME >>>> variable. Also use the MSVC command prompt for x86_64 so cl and >>>> nmake are on your path. >>> >>> This is very odd. The CVS version of the code does not contain >>> this file. Do you keep the latest code somewhere else? >>> >>> Gili >>> From tjarvi at qbang.org Sun Apr 5 16:13:27 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Apr 2009 16:13:27 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D920F9.6080702@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> <49D919A7.1070806@bbs.darktech.org> <49D920F9.6080702@bbs.darktech.org> Message-ID: Hi Gili, Are you using the cvs version? I thought we fixed the linked list issues. A solution was posted to the list. Let me look at work tomorrow to see what I have. On Sun, 5 Apr 2009, cowwoc wrote: > > My mistake. The problem in YACK is real, but it isn't the real cause > of the crash. The crash is caused by termios.c line 1099: > > index->prev->next = port; > > because in my case "index->prev==0". I think the bug is that the code > assumes that index will contain a minimum of two entries if we're inserting a > previously closed fd. In my case, it only contains one. > > I'm not sure why you have this code branch (as opposed to appending > to the end of index). Please take a look. > > Thanks, > Gili > > cowwoc wrote: >> >> Okay, I tracked down the crash. It's being caused by YACK() using a >> 80-character buffer. The error message is longer than 80 characters, so >> _snprintf_s() crashes to avoid a buffer overflow. >> >> Please apply the attached patch and add the zipped up Visual Studio >> project directory. It's not perfect yet but it's a good start. >> >> Gili >> >> Trent Jarvi wrote: >>> >>> CVS HEAD is currently the rxtx 2.0 code. A branch was created long ago >>> for 'experimental' gnu.io work. It just happens that the branch is what >>> everyone uses now. >>> >>> checkout -r commapi-0-0-1 rxtx-devel >>> >>> will get the branch >>> >>> On Sun, 5 Apr 2009, cowwoc wrote: >>> >>>> Trent Jarvi wrote: >>>>> It will compile with the msvc cl.exe and nmake. See Makefile.msvc in >>>>> the top level directory. You will need to adjust the JAVA_HOME >>>>> variable. Also use the MSVC command prompt for x86_64 so cl and nmake >>>>> are on your path. >>>> >>>> This is very odd. The CVS version of the code does not contain this >>>> file. Do you keep the latest code somewhere else? >>>> >>>> Gili >>>> > From ilkka at myller.com Sun Apr 5 23:58:08 2009 From: ilkka at myller.com (Ilkka Myller) Date: Mon, 6 Apr 2009 08:58:08 +0300 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> <49D919A7.1070806@bbs.darktech.org> <49D920F9.6080702@bbs.darktech.org> Message-ID: <19779C97-E0C7-4E3D-B715-F84F50F00CE6@myller.com> Hi all, I've already submitted the patch to fix this issue in february: http://mailman.qbang.org/pipermail/rxtx/2009-February/3989441.html The patch fixes the mentioned doubly linked list handling in termios.c -- I Trent Jarvi kirjoitti 6.4.2009 kello 1.13: > > Hi Gili, > > Are you using the cvs version? I thought we fixed the linked list > issues. > A solution was posted to the list. Let me look at work tomorrow to > see > what I have. > > > > On Sun, 5 Apr 2009, cowwoc wrote: > >> >> My mistake. The problem in YACK is real, but it isn't the real cause >> of the crash. The crash is caused by termios.c line 1099: >> >> index->prev->next = port; >> >> because in my case "index->prev==0". I think the bug is that the >> code >> assumes that index will contain a minimum of two entries if we're >> inserting a >> previously closed fd. In my case, it only contains one. >> >> I'm not sure why you have this code branch (as opposed to appending >> to the end of index). Please take a look. >> >> Thanks, >> Gili >> >> cowwoc wrote: >>> >>> Okay, I tracked down the crash. It's being caused by YACK() >>> using a >>> 80-character buffer. The error message is longer than 80 >>> characters, so >>> _snprintf_s() crashes to avoid a buffer overflow. >>> >>> Please apply the attached patch and add the zipped up Visual >>> Studio >>> project directory. It's not perfect yet but it's a good start. >>> >>> Gili >>> >>> Trent Jarvi wrote: >>>> >>>> CVS HEAD is currently the rxtx 2.0 code. A branch was created >>>> long ago >>>> for 'experimental' gnu.io work. It just happens that the branch >>>> is what >>>> everyone uses now. >>>> >>>> checkout -r commapi-0-0-1 rxtx-devel >>>> >>>> will get the branch >>>> >>>> On Sun, 5 Apr 2009, cowwoc wrote: >>>> >>>>> Trent Jarvi wrote: >>>>>> It will compile with the msvc cl.exe and nmake. See >>>>>> Makefile.msvc in >>>>>> the top level directory. You will need to adjust the JAVA_HOME >>>>>> variable. Also use the MSVC command prompt for x86_64 so cl and >>>>>> nmake >>>>>> are on your path. >>>>> >>>>> This is very odd. The CVS version of the code does not >>>>> contain this >>>>> file. Do you keep the latest code somewhere else? >>>>> >>>>> Gili >>>>> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Steffen.DETTMER at ingenico.com Mon Apr 6 02:53:47 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 6 Apr 2009 10:53:47 +0200 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D919A7.1070806@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> <49D919A7.1070806@bbs.darktech.org> Message-ID: <20090406085347.GM8289@elberon.bln.de.ingenico.com> Hi, just two minor details, first about the errno change, I though #include extern int errno; is correct (POSIX.1) - why this change? second about the log message, I think the maximum length could be limited and the return value of malloc must be checked for != NULL before using. Should it be _snprintf_s( message, 80, _TRUNCATE, "Error 0x%x at %s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); (I know that MS-CRT _snprintf does not guarantee to have a final EOS, but I think _snprintf_s with _TRUNCATE does so?). If it is known that truncation may happen maybe sizeof[message] could be increased; maybe using some %.20s could be used avoiding __FILE__ including big pathes to a message where all the message had been cut-off. To have it portable I think it could be: /* generally: */ #if defined(_MSC_VER) # define snprintf _snprintf #endif snprintf(message, sizeof(message), "Error 0x%x at %.20s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); message[sizeof(message)-1] = '\0'; /* needed for MS CRT snprintf */ (for length and size parameter I think size_t could be an option, but on several platforms, including MS-CRT and older glibc, there is no %z, unfortunately) oki, Steffen * cowwoc wrote on Sun, Apr 05, 2009 at 16:50 -0400: > > Okay, I tracked down the crash. It's being caused by YACK() using a > 80-character buffer. The error message is longer than 80 characters, so > _snprintf_s() crashes to avoid a buffer overflow. > > Please apply the attached patch and add the zipped up Visual Studio > project directory. It's not perfect yet but it's a good start. > > Gili > > Trent Jarvi wrote: > > > >CVS HEAD is currently the rxtx 2.0 code. A branch was created long > >ago for 'experimental' gnu.io work. It just happens that the branch > >is what everyone uses now. > > > >checkout -r commapi-0-0-1 rxtx-devel > > > >will get the branch > > > >On Sun, 5 Apr 2009, cowwoc wrote: > > > >>Trent Jarvi wrote: > >>>It will compile with the msvc cl.exe and nmake. See Makefile.msvc > >>>in the top level directory. You will need to adjust the JAVA_HOME > >>>variable. Also use the MSVC command prompt for x86_64 so cl and > >>>nmake are on your path. > >> > >> This is very odd. The CVS version of the code does not contain > >>this file. Do you keep the latest code somewhere else? > >> > >>Gili > >> > Index: ParallelImp.c > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/ParallelImp.c,v > retrieving revision 1.15.2.36 > diff -u -r1.15.2.36 ParallelImp.c > --- ParallelImp.c 11 Feb 2009 01:04:19 -0000 1.15.2.36 > +++ ParallelImp.c 5 Apr 2009 17:55:23 -0000 > @@ -119,7 +119,7 @@ > # include > #endif > > -extern int errno; > +_CRTIMP extern int * __cdecl _errno(void); > > #include "ParallelImp.h" > > @@ -181,8 +181,6 @@ > > #if defined (WIN32) > > -#define CTL_CODE( DeviceType, Function, Method, Access ) (((DeviceType) << 16) | ((Access) << 14) | ((Function) << 2) | (Method)) > - > #define FILE_DEVICE_PARALLEL_PORT 0x00000016 > #define METHOD_BUFFERED 0 > #define FILE_ANY_ACCESS 0 > @@ -253,7 +251,6 @@ > jobject jobj) > { > int fd = get_java_var( env, jobj,"fd","I" ); > - int status; > #if defined (__linux__) > ioctl(fd, LPGETSTATUS, &status); > #elif defined (WIN32) > Index: SerialImp.c > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v > retrieving revision 1.46.2.203 > diff -u -r1.46.2.203 SerialImp.c > --- SerialImp.c 19 Mar 2009 03:27:48 -0000 1.46.2.203 > +++ SerialImp.c 5 Apr 2009 17:49:48 -0000 > @@ -147,7 +147,7 @@ > #include > #endif /* LIBLOCKDEV */ > > -extern int errno; > +_CRTIMP extern int * __cdecl _errno(void); > > #include "SerialImp.h" > > Index: termios.c > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/termios.c,v > retrieving revision 1.9.2.62 > diff -u -r1.9.2.62 termios.c > --- termios.c 13 Jan 2009 03:08:55 -0000 1.9.2.62 > +++ termios.c 5 Apr 2009 17:54:09 -0000 > @@ -88,7 +88,7 @@ > #define SIGIO 0 > > int my_errno; > -extern int errno; > +_CRTIMP extern int * __cdecl _errno(void); > struct termios_list > { > char filename[80]; > @@ -1350,7 +1350,7 @@ > In that case use EAGAIN. See SerialImp.c:testRead() > ----------------------------------------------------------*/ > > -int serial_read( int fd, void *vb, int size ) > +int serial_read( int fd, void *vb, unsigned int size ) > { > long start, now; > unsigned long nBytes = 0, total = 0, error; > Index: win32termios.h > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/win32termios.h,v > retrieving revision 1.5.2.34 > diff -u -r1.5.2.34 win32termios.h > --- win32termios.h 5 Feb 2009 01:25:05 -0000 1.5.2.34 > +++ win32termios.h 5 Apr 2009 20:29:30 -0000 > @@ -60,6 +60,7 @@ > #include > #include > #include > +#include > #ifdef TRACE > #define ENTER(x) report("entering "x" \n"); > #define LEAVE(x) report("leaving "x" \n"); > @@ -70,8 +71,9 @@ > #if defined(_MSC_VER) > #define YACK() \ > { \ > - char *allocTextBuf, message[80]; \ > - unsigned long nChars; \ > + char *allocTextBuf, *message; \ > + const unsigned short longestNumber = 20; \ > + unsigned long nChars, len; \ > unsigned int errorCode = GetLastError(); \ > nChars = FormatMessage ( \ > FORMAT_MESSAGE_ALLOCATE_BUFFER | \ > @@ -82,8 +84,12 @@ > (LPSTR)&allocTextBuf, \ > 16, \ > NULL ); \ > - _snprintf_s( message, 80, 80, "Error 0x%x at %s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); \ > + len = strlen("Error 0x") + longestNumber + strlen(" at ") + strlen(__FILE__) + longestNumber + \ > + strlen(": ") + ((nChars+1) * sizeof(TCHAR)) + 1; \ > + message = malloc(len); \ > + _snprintf_s( message, len, len - 1, "Error 0x%x at %s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); \ > report_error( message ); \ > + free(message); \ > LocalFree(allocTextBuf); \ > Sleep(1); \ > } > @@ -173,7 +179,7 @@ > int serial_test( char * ); > int serial_open(const char *File, int flags, ... ); > int serial_close(int fd); > -int serial_read(int fd, void *b, int size); > +int serial_read(int fd, void *b, unsigned int size); > int serial_write(int fd, char *Str, int length); > /* > * lcc winsock.h conflicts > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx End of message. ------------------------------------------------------------------->8======= About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From bill7007 at gmail.com Mon Apr 6 16:34:50 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Mon, 6 Apr 2009 18:34:50 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: <49D693BA.8060909@gatworks.com> References: <49D546F8.20807@gatworks.com> <49D693BA.8060909@gatworks.com> Message-ID: Once it hung, three stack dumps minutes apart were exactly the same. I have a noticed that when it hangs, the read appears after flush() enter and before flush leave() that doesn't happen like: RXTXPort:SerialOutputStream:flush() enter RXTXPort:SerialInputStream:read(8192 0 8192) called When it works, flush() enter and leave happen together. It may just be because flush() hangs and read is the only other thread waiting to run at that point. I don't know much about the RXTX design and kernel interaction, just digging through the code some. Is there a design description somewhere? Am hung up on target system compile since UTS_RELEASE seems no longer defined for 2.6.18 up kernels and have not figured a good patch yet. But, that is another issue. Thanks for the good help. On Fri, Apr 3, 2009 at 6:54 PM, U. George wrote: > I would have tried 2 or 3 "^\" . If things are stuck, then all will be at > same 'java' instruction. If thread is moving, then one of the snapshots > would be different. > > I *think* flushing/draining wont return until the kernel buffers to device > have been accepted by device. Stuck/paused device? > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090406/c4b509d8/attachment-0013.html From tjarvi at qbang.org Mon Apr 6 17:45:38 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 6 Apr 2009 17:45:38 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <20090406085347.GM8289@elberon.bln.de.ingenico.com> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> <49D919A7.1070806@bbs.darktech.org> <20090406085347.GM8289@elberon.bln.de.ingenico.com> Message-ID: The error bits in the patch can probably just be dropped out. I don't see what they solve. Your snprintf define appears to work. The following is what I'd like to put in if noone objects. #if defined(_MSC_VER) # define snprintf _snprintf #endif #define YACK() \ { \ char *allocTextBuf, message[80]; \ unsigned long nChars; \ unsigned int errorCode = GetLastError(); \ nChars = FormatMessage ( \ FORMAT_MESSAGE_ALLOCATE_BUFFER | \ FORMAT_MESSAGE_FROM_SYSTEM, \ NULL, \ errorCode, \ MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT), \ (LPSTR)&allocTextBuf, \ 16, \ NULL ); \ snprintf( message, 80, "Error 0x%x at %s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); \ message[sizeof(message)-1] = '\0'; /* needed for MS CRT snprintf */ \ report_error( message ); \ LocalFree(allocTextBuf); \ Sleep(1); \ } On Mon, 6 Apr 2009, Steffen DETTMER wrote: > Hi, > > just two minor details, first about the errno change, I though > > #include > extern int errno; > > is correct (POSIX.1) - why this change? > > second about the log message, I think the maximum length could be > limited and the return value of malloc must be checked for != > NULL before using. > > Should it be > > _snprintf_s( message, 80, _TRUNCATE, "Error 0x%x at %s(%d): %s\n", > errorCode, __FILE__, __LINE__, allocTextBuf); > > (I know that MS-CRT _snprintf does not guarantee to have a final > EOS, but I think _snprintf_s with _TRUNCATE does so?). > > If it is known that truncation may happen maybe sizeof[message] > could be increased; maybe using some %.20s could be used avoiding > __FILE__ including big pathes to a message where all the message > had been cut-off. > > To have it portable I think it could be: > > /* generally: */ > #if defined(_MSC_VER) > # define snprintf _snprintf > #endif > > snprintf(message, sizeof(message), "Error 0x%x at %.20s(%d): %s\n", > errorCode, __FILE__, __LINE__, allocTextBuf); > message[sizeof(message)-1] = '\0'; /* needed for MS CRT snprintf */ > > (for length and size parameter I think size_t could be an option, > but on several platforms, including MS-CRT and older glibc, > there is no %z, unfortunately) > > oki, > > Steffen > > > * cowwoc wrote on Sun, Apr 05, 2009 at 16:50 -0400: >> >> Okay, I tracked down the crash. It's being caused by YACK() using a >> 80-character buffer. The error message is longer than 80 characters, so >> _snprintf_s() crashes to avoid a buffer overflow. >> >> Please apply the attached patch and add the zipped up Visual Studio >> project directory. It's not perfect yet but it's a good start. >> >> Gili >> >> Trent Jarvi wrote: >> > >> >CVS HEAD is currently the rxtx 2.0 code. A branch was created long >> >ago for 'experimental' gnu.io work. It just happens that the branch >> >is what everyone uses now. >> > >> >checkout -r commapi-0-0-1 rxtx-devel >> > >> >will get the branch >> > >> >On Sun, 5 Apr 2009, cowwoc wrote: >> > >> >>Trent Jarvi wrote: >> >>>It will compile with the msvc cl.exe and nmake. See Makefile.msvc >> >>>in the top level directory. You will need to adjust the JAVA_HOME >> >>>variable. Also use the MSVC command prompt for x86_64 so cl and >> >>>nmake are on your path. >> >> >> >> This is very odd. The CVS version of the code does not contain >> >>this file. Do you keep the latest code somewhere else? >> >> >> >>Gili >> >> > >> Index: ParallelImp.c >> =================================================================== >> RCS file: /usr/local/cvsroot/rxtx-devel/src/ParallelImp.c,v >> retrieving revision 1.15.2.36 >> diff -u -r1.15.2.36 ParallelImp.c >> --- ParallelImp.c 11 Feb 2009 01:04:19 -0000 1.15.2.36 >> +++ ParallelImp.c 5 Apr 2009 17:55:23 -0000 >> @@ -119,7 +119,7 @@ >> # include >> #endif >> >> -extern int errno; >> +_CRTIMP extern int * __cdecl _errno(void); >> >> #include "ParallelImp.h" >> >> @@ -181,8 +181,6 @@ >> >> #if defined (WIN32) >> >> -#define CTL_CODE( DeviceType, Function, Method, Access ) (((DeviceType) << 16) | ((Access) << 14) | ((Function) << 2) | (Method)) >> - >> #define FILE_DEVICE_PARALLEL_PORT 0x00000016 >> #define METHOD_BUFFERED 0 >> #define FILE_ANY_ACCESS 0 >> @@ -253,7 +251,6 @@ >> jobject jobj) >> { >> int fd = get_java_var( env, jobj,"fd","I" ); >> - int status; >> #if defined (__linux__) >> ioctl(fd, LPGETSTATUS, &status); >> #elif defined (WIN32) >> Index: SerialImp.c >> =================================================================== >> RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v >> retrieving revision 1.46.2.203 >> diff -u -r1.46.2.203 SerialImp.c >> --- SerialImp.c 19 Mar 2009 03:27:48 -0000 1.46.2.203 >> +++ SerialImp.c 5 Apr 2009 17:49:48 -0000 >> @@ -147,7 +147,7 @@ >> #include >> #endif /* LIBLOCKDEV */ >> >> -extern int errno; >> +_CRTIMP extern int * __cdecl _errno(void); >> >> #include "SerialImp.h" >> >> Index: termios.c >> =================================================================== >> RCS file: /usr/local/cvsroot/rxtx-devel/src/termios.c,v >> retrieving revision 1.9.2.62 >> diff -u -r1.9.2.62 termios.c >> --- termios.c 13 Jan 2009 03:08:55 -0000 1.9.2.62 >> +++ termios.c 5 Apr 2009 17:54:09 -0000 >> @@ -88,7 +88,7 @@ >> #define SIGIO 0 >> >> int my_errno; >> -extern int errno; >> +_CRTIMP extern int * __cdecl _errno(void); >> struct termios_list >> { >> char filename[80]; >> @@ -1350,7 +1350,7 @@ >> In that case use EAGAIN. See SerialImp.c:testRead() >> ----------------------------------------------------------*/ >> >> -int serial_read( int fd, void *vb, int size ) >> +int serial_read( int fd, void *vb, unsigned int size ) >> { >> long start, now; >> unsigned long nBytes = 0, total = 0, error; >> Index: win32termios.h >> =================================================================== >> RCS file: /usr/local/cvsroot/rxtx-devel/src/win32termios.h,v >> retrieving revision 1.5.2.34 >> diff -u -r1.5.2.34 win32termios.h >> --- win32termios.h 5 Feb 2009 01:25:05 -0000 1.5.2.34 >> +++ win32termios.h 5 Apr 2009 20:29:30 -0000 >> @@ -60,6 +60,7 @@ >> #include >> #include >> #include >> +#include >> #ifdef TRACE >> #define ENTER(x) report("entering "x" \n"); >> #define LEAVE(x) report("leaving "x" \n"); >> @@ -70,8 +71,9 @@ >> #if defined(_MSC_VER) >> #define YACK() \ >> { \ >> - char *allocTextBuf, message[80]; \ >> - unsigned long nChars; \ >> + char *allocTextBuf, *message; \ >> + const unsigned short longestNumber = 20; \ >> + unsigned long nChars, len; \ >> unsigned int errorCode = GetLastError(); \ >> nChars = FormatMessage ( \ >> FORMAT_MESSAGE_ALLOCATE_BUFFER | \ >> @@ -82,8 +84,12 @@ >> (LPSTR)&allocTextBuf, \ >> 16, \ >> NULL ); \ >> - _snprintf_s( message, 80, 80, "Error 0x%x at %s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); \ >> + len = strlen("Error 0x") + longestNumber + strlen(" at ") + strlen(__FILE__) + longestNumber + \ >> + strlen(": ") + ((nChars+1) * sizeof(TCHAR)) + 1; \ >> + message = malloc(len); \ >> + _snprintf_s( message, len, len - 1, "Error 0x%x at %s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); \ >> report_error( message ); \ >> + free(message); \ >> LocalFree(allocTextBuf); \ >> Sleep(1); \ >> } >> @@ -173,7 +179,7 @@ >> int serial_test( char * ); >> int serial_open(const char *File, int flags, ... ); >> int serial_close(int fd); >> -int serial_read(int fd, void *b, int size); >> +int serial_read(int fd, void *b, unsigned int size); >> int serial_write(int fd, char *Str, int length); >> /* >> * lcc winsock.h conflicts >> > > >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > > > > > > > > > > > > End of message. > ------------------------------------------------------------------->8======= > > > About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. > This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > P Please consider the environment before printing this e-mail > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Apr 6 18:11:28 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 6 Apr 2009 18:11:28 -0600 (MDT) Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: <49D546F8.20807@gatworks.com> <49D693BA.8060909@gatworks.com> Message-ID: UTS_RELEASE is defined in now. The check really should be removed from RXTX. It was a defensive check for wilder times when GNU glibc did not have defines the kernel headers had so rxtx would include the kernel headers instead. :/ If you don't have linux/version.h, it is generated when you configure the kernel. make oldconfig used to do the trick. It may make sense to work with the prerelease or CVS code. RXTX just assumes that flush, read and anything else the kernel exposes may be called at anytime from any thread. There isn't a design for the kernel interaction. There are higher level constraints put in Java to prevent some things happening at the same time with 'synchronized.' RXTXPort.java has all of those. When the port is opened, a native event thread is started which uses select to know if an event has happened. BSD like systems have a native thread that fires off on write which tries to flush() to determine when the output buffer is empty asynchronously. The rest is not marshaled in any fashion at the native level. T I think there is a lower level deadlock being triggered in flush as well. I don't think it should be possible if everything was right underneath us. You may want to examine the java code closer to make sure it isnt possible the lock is there. On Mon, 6 Apr 2009, Bill Johnson wrote: > Once it hung, three stack dumps minutes apart were exactly the same. > I have a noticed that when it hangs, the read appears after flush() enter and > before flush leave() that doesn't happen like: > RXTXPort:SerialOutputStream:flush() enter > RXTXPort:SerialInputStream:read(8192 0 8192) called > > When it works, flush() enter and leave happen together. It may just be because > flush() hangs and read is the only other thread waiting to run at that point. > I don't know much about the RXTX design and kernel interaction, just digging > through the code some. Is there a design description somewhere? > > Am hung up on target system compile since UTS_RELEASE seems no longer defined for > 2.6.18 up kernels and have not figured a good patch yet. But, that is another > issue. > > Thanks for the good help. > > > On Fri, Apr 3, 2009 at 6:54 PM, U. George wrote: > I would have tried 2 or 3 "^\" . If things are stuck, then all will be > at same 'java' instruction. If thread is moving, then one of the > snapshots would be different. > > I *think* flushing/draining wont return until the kernel buffers to > device have been accepted by device. Stuck/paused device? > > > > > From tjarvi at qbang.org Mon Apr 6 18:28:50 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 6 Apr 2009 18:28:50 -0600 (MDT) Subject: [Rxtx] CVS updates. Pre3 is comming. Message-ID: I need to go through the bugzilla reports prior to the pre3 release. I think this should be close if you want to check it out from CVS. added: YACK() debug overflow fix for windows Steffen DETTMER (and many others) multiport fix for windows. Ilkka Myller http://mailman.qbang.org/pipermail/rxtx/2009-February/3989441.html I think this code is current. If I missed something, yell. CVS Info: export/setenv CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login # passwd mousy cvs checkout -r commapi-0-0-1 rxtx-devel -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Apr 6 22:32:07 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 6 Apr 2009 22:32:07 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D919A7.1070806@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> <49D919A7.1070806@bbs.darktech.org> Message-ID: Ah. I'll put this in CVS tomorrow. I did sync up the code with my work sandbox today. I just forgot to pull and add this. On Sun, 5 Apr 2009, cowwoc wrote: > > Okay, I tracked down the crash. It's being caused by YACK() using a > 80-character buffer. The error message is longer than 80 characters, so > _snprintf_s() crashes to avoid a buffer overflow. > > Please apply the attached patch and add the zipped up Visual Studio > project directory. It's not perfect yet but it's a good start. > > Gili > > Trent Jarvi wrote: >> >> CVS HEAD is currently the rxtx 2.0 code. A branch was created long ago for >> 'experimental' gnu.io work. It just happens that the branch is what >> everyone uses now. >> >> checkout -r commapi-0-0-1 rxtx-devel >> >> will get the branch >> >> On Sun, 5 Apr 2009, cowwoc wrote: >> >>> Trent Jarvi wrote: >>>> It will compile with the msvc cl.exe and nmake. See Makefile.msvc in the >>>> top level directory. You will need to adjust the JAVA_HOME variable. >>>> Also use the MSVC command prompt for x86_64 so cl and nmake are on your >>>> path. >>> >>> This is very odd. The CVS version of the code does not contain this >>> file. Do you keep the latest code somewhere else? >>> >>> Gili >>> > From cowwoc at bbs.darktech.org Tue Apr 7 06:07:46 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Tue, 07 Apr 2009 08:07:46 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: References: Message-ID: <49DB4212.40807@bbs.darktech.org> > just two minor details, first about the errno change, I though > > #include > extern int errno; > > is correct (POSIX.1) - why this change? If you compile this under Visual Studio 2008 you will get warnings that the errno type being imported is different from the type being exported. The definition I pasted is the one being exported. Perhaps we should use #ifdef WIN32 for this? Gili From bill7007 at gmail.com Tue Apr 7 17:58:54 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Tue, 7 Apr 2009 19:58:54 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: <49D546F8.20807@gatworks.com> <49D693BA.8060909@gatworks.com> Message-ID: I have traced the hang down to a call to tcdrain(fd) in SerialImp.c:drain() running and rebuilt under Netbeans on the target machine with debug messages on. That puts it into the system code, so I'm not sure how to proceed. I guess I could debug into the kernel source but I've not done that. I saw some discussion about an IOCTL that sets/adjusts a timeout on tcdrain() but that may have been for BSD. Maybe there is some new setup requirement or bug introduced with this 2.6.18 kernel or a hardware difference. Below is a message listing with some of the repeated parts removed. Maybe you can see something noteworthy? JNI_OnLoad called. WARNING: RXTX Version mismatch Jar version = RXTX-2.2pre2 native lib Version = RXTX-2.2pre3 entering RXTXCommDriver:getDeviceDirectory entering RXTXPort:testRead fhs_lock: creating lockfile: 29704 fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXPort:testRead RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB2 fhs_lock: creating lockfile: 29704 fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXPort:testRead RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB1 fhs_lock: creating lockfile: 29704 fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXPort:testRead RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB0 fhs_lock: creating lockfile: 29704 fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXPort:testRead fhs_lock: creating lockfile: 29704 ... REPEATS fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXPort:testRead fhs_lock: creating lockfile: 29704 fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXCommDriver:getDeviceDirectory entering RXTXPort:testRead fhs_lock: creating lockfile: 29704 ...REPEATS fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXPort:testRead fhs_lock: creating lockfile: 29704 fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXPort:Initialize RXTX WARNING: This library was compiled to run with OS release 2.6.18 and you are currently running OS release 2.6.18-92.1.6.el5. In some cases this can be a problem. Try recompiling RXTX if you notice strange behavior. If you just compiled RXTX make sure /usr/include/linux is a symbolic link to the include files that came with the kernel source and not an older copy. press enter to continue leaving RXTXPort:Initialize entering RXTXPort:open fhs_lock: creating lockfile: 29704 open: locking worked for /dev/ttyUSB2 open: fd returned is 9 leaving RXTXPort:open entering eventLoop has_line_status_register_acess: Port does not support TIOCSERGETLSR driver_has_tiocgicount: Port does not support TIOCGICOUNT events init_threads: get eis init_threads: set eis init_threads: stop leaving RXTXPort:translate_speed entering RXTXPort:nativeSetSerialPortParams entering translate_date_bits entering translate_stop_bits leaving RXTXPort:translate_stop_bits entering translate_parity leaving translate_parity entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 ...REPEATS entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 leaving RXTXPort:nativeSetSerialPortParams entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 ...REPEATS entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 entering writeArray entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 writeArray() leaving RXTXPort:writeArray entering SerialImp.c:drain() nativeDrain: trying tcdrain RXTXPort:drain() returns: 0 leaving RXTXPort:drain() entering writeArray writeArray() leaving RXTXPort:writeArray entering SerialImp.c:drain() nativeDrain: trying tcdrain entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 Tue Apr 07 18:51:49 EDT 2009:TSerial[22]:Using Port:/dev/ttyUSB2 Tue Apr 07 18:51:49 EDT 2009:TSerial[22].Transmit:TN Tue Apr 07 18:51:49 EDT 2009:TSerial[22].Transmit:RV entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 ...REPEATS FOREVER? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090407/f26e5752/attachment-0012.html From tjarvi at qbang.org Tue Apr 7 18:31:23 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 7 Apr 2009 18:31:23 -0600 (MDT) Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: <49D546F8.20807@gatworks.com> <49D693BA.8060909@gatworks.com> Message-ID: On Tue, 7 Apr 2009, Bill Johnson wrote: > I have traced the hang down to a call to tcdrain(fd) in SerialImp.c:drain() > running and rebuilt under Netbeans on the target machine with debug messages > on. That puts it into the system code, so I'm not sure how to proceed. I > guess I could debug into the kernel source but I've not done that. I saw > some discussion about an IOCTL that sets/adjusts a timeout on tcdrain() but > that may have been for BSD. Maybe there is some new setup requirement or bug > introduced with this 2.6.18 kernel or a hardware difference. > Below is a message listing with some of the repeated parts removed. Maybe > you can see something noteworthy? > > JNI_OnLoad called. > WARNING:? RXTX Version mismatch > ??????? Jar version = RXTX-2.2pre2 > ??????? native lib Version = RXTX-2.2pre3 > entering RXTXCommDriver:getDeviceDirectory > entering RXTXPort:testRead > fhs_lock: creating lockfile:????? 29704 > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXPort:testRead > RXTX Warning:? Removing stale lock file. /var/lock/LCK..ttyUSB2 > fhs_lock: creating lockfile:????? 29704 > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXPort:testRead > RXTX Warning:? Removing stale lock file. /var/lock/LCK..ttyUSB1 > fhs_lock: creating lockfile:????? 29704 > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXPort:testRead > RXTX Warning:? Removing stale lock file. /var/lock/LCK..ttyUSB0 > fhs_lock: creating lockfile:????? 29704 > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXPort:testRead > fhs_lock: creating lockfile:????? 29704 > > ... REPEATS > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXPort:testRead > fhs_lock: creating lockfile:????? 29704 > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXCommDriver:getDeviceDirectory > entering RXTXPort:testRead > fhs_lock: creating lockfile:????? 29704 > > ...REPEATS > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXPort:testRead > fhs_lock: creating lockfile:????? 29704 > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXPort:Initialize > > > > RXTX WARNING:? This library was compiled to run with OS release 2.6.18 and > you are currently running OS release 2.6.18-92.1.6.el5.? In some cases this > can be a problem.? Try recompiling RXTX if you notice strange behavior.? If > you just compiled RXTX make sure /usr/include/linux is a symbolic link to > the include files that came with the kernel source and not an older copy. > > > press enter to continue > > leaving RXTXPort:Initialize > entering RXTXPort:open > fhs_lock: creating lockfile:????? 29704 > > open: locking worked for /dev/ttyUSB2 > open: fd returned is 9 > leaving RXTXPort:open > entering eventLoop > ? > has_line_status_register_acess: Port does not support TIOCSERGETLSR > ?driver_has_tiocgicount:? Port does not support TIOCGICOUNT events > init_threads: get eis > init_threads: set eis > init_threads:? stop > leaving RXTXPort:translate_speed > entering RXTXPort:nativeSetSerialPortParams > entering translate_date_bits > entering translate_stop_bits > leaving RXTXPort:translate_stop_bits > entering translate_parity > leaving translate_parity > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > ...REPEATS > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > leaving RXTXPort:nativeSetSerialPortParams > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > ...REPEATS > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > entering writeArray > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > writeArray() > leaving RXTXPort:writeArray > entering SerialImp.c:drain() > nativeDrain: trying tcdrain > RXTXPort:drain() returns: 0 > leaving RXTXPort:drain() > entering writeArray > writeArray() > leaving RXTXPort:writeArray > entering SerialImp.c:drain() > nativeDrain: trying tcdrain > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > Tue Apr 07 18:51:49 EDT 2009:TSerial[22]:Using Port:/dev/ttyUSB2 > Tue Apr 07 18:51:49 EDT 2009:TSerial[22].Transmit:TN > > Tue Apr 07 18:51:49 EDT 2009:TSerial[22].Transmit:RV > > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > ...REPEATS FOREVER? > > > Hi Bill ugh. The tiocmget... is the eventLoop checking for events. It sits with select() but has a timeout value to keep it spinning at a trivial rate. tcdrain() is the suspect. I don't see anything in the code that looks like a problem. If flow control is not enabled, I don't see a reason for it not to return. Given that this is USB, perhaps a message from the device got lost. Onboard UARTs would have a status register change when output buffer is empty. USB needs to communicate the event as an HID device which may be the source of the error. Dropping back to onboard UARTs eliminates that portion of the mix. What vendor/chipset is the USB dongle? I understand code has been pushed upon the linux serial devices for new for things like acpi. There very well could be a bug introduced. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Apr 7 18:38:22 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 7 Apr 2009 18:38:22 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49DB4212.40807@bbs.darktech.org> References: <49DB4212.40807@bbs.darktech.org> Message-ID: On Tue, 7 Apr 2009, cowwoc wrote: >> just two minor details, first about the errno change, I though >> >> #include >> extern int errno; >> >> is correct (POSIX.1) - why this change? > > If you compile this under Visual Studio 2008 you will get warnings that > the errno type being imported is different from the type being exported. > The definition I pasted is the one being exported. Perhaps we should use > #ifdef WIN32 for this? > Hi Gili, Perhaps a workaround for _MSVC is in order. GNU compilers for windows won't complain. If it's a question of MSVC or POSIX being right, the library favors the standard as a stated goal. I'm not sure what MSVC is using errno for but it should not be using it except with POSIX extensions. Perhaps #undef is enough to get rid of the warning and (maybe) has no ill consequences. Newer windows have POSIX extensions that may show how Microsoft solved the problem. It can probably fester. -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Tue Apr 7 19:54:06 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Tue, 07 Apr 2009 21:54:06 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: References: <49DB4212.40807@bbs.darktech.org> Message-ID: <49DC03BE.5010203@bbs.darktech.org> Trent Jarvi wrote: > I'm not sure what MSVC is using errno for but it should not be using it > except with POSIX extensions. Perhaps #undef is enough to get rid of > the warning and (maybe) has no ill consequences. Newer windows have > POSIX extensions that may show how Microsoft solved the problem. > > It can probably fester. What does "newer windows" refer to in this case? I was compiling using Visual Studio 2008 sp1 under Windows Vista. Both are cutting edge technologies as far as official releases go. I think you're best suited to judge whether this warning is a big deal or not so I think you should see it for yourself. Please try firing up Visual Studio 2008 (express?) against the project I sent you. Gili From Steffen.DETTMER at ingenico.com Wed Apr 8 05:50:42 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 8 Apr 2009 13:50:42 +0200 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49DC03BE.5010203@bbs.darktech.org> References: <49DB4212.40807@bbs.darktech.org> <49DC03BE.5010203@bbs.darktech.org> Message-ID: <20090408115042.GC5090@elberon.bln.de.ingenico.com> * cowwoc wrote on Tue, Apr 07, 2009 at 21:54 -0400: > Trent Jarvi wrote: > > I'm not sure what MSVC is using errno for but it should not be using it > > except with POSIX extensions. Perhaps #undef is enough to get rid of > > the warning and (maybe) has no ill consequences. Newer windows have > > POSIX extensions that may show how Microsoft solved the problem. I think here best is simply to omit this old^Wclassic `extern int errno;' line completely. I think standards just say something like `implementations may support the declaration extern int errno;'. About POSIX extensions I think in general it should be considered that althrough many things are available, even with MS Visual C++, the Microsoft tools lead developers to write non-portable code (and personally I think this is intentional). For example, they call the official ISO-C function `strerror' deprecated (!) and twaddle about some security enhancements (without even beeing specific). Someone could, because of this, lead to use the MS specific, unportable `strerror_s' instead. Even better, at _strerror_s they tell, for `ANSI compatiblity someone should use strerror_s'. Of course a program using [_]strerror_s won't be ANSI-C compliant. Do they mean strerror_r? _strerror_s has the same parameters - but of course in different order - to make porting a pain... SCNR. > What does "newer windows" refer to in this case? I was compiling using > Visual Studio 2008 sp1 under Windows Vista. Both are cutting edge > technologies as far as official releases go. `cutting edge technologies' yeah post-standard, portability-cutting technologies smoothing the way to MS world domination; own post-ANSI-C programming languages help (maybe to increase the share holder value)... SCNR. > I think you're best suited to judge whether this warning is a big deal > or not so I think you should see it for yourself. Please try firing up > Visual Studio 2008 (express?) against the project I sent you. yeah, getting the CL.EXE of 2008 running in a normal command line environment (without its special `C++ Shell') is a bit tricky - but possible. ;) oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From tjarvi at qbang.org Wed Apr 8 14:29:54 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 8 Apr 2009 14:29:54 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49DC03BE.5010203@bbs.darktech.org> References: <49DB4212.40807@bbs.darktech.org> <49DC03BE.5010203@bbs.darktech.org> Message-ID: The support has been around for a long time to. I don't know the details but the support appears to be tied to the OS. http://en.wikipedia.org/wiki/POSIX#POSIX_for_Windows On Tue, 7 Apr 2009, cowwoc wrote: > Trent Jarvi wrote: >> I'm not sure what MSVC is using errno for but it should not be using it >> except with POSIX extensions. Perhaps #undef is enough to get rid of the >> warning and (maybe) has no ill consequences. Newer windows have POSIX >> extensions that may show how Microsoft solved the problem. >> >> It can probably fester. > > What does "newer windows" refer to in this case? I was compiling > using Visual Studio 2008 sp1 under Windows Vista. Both are cutting edge > technologies as far as official releases go. > > I think you're best suited to judge whether this warning is a big > deal or not so I think you should see it for yourself. Please try firing up > Visual Studio 2008 (express?) against the project I sent you. > > Gili > From bill7007 at gmail.com Wed Apr 8 15:59:08 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Wed, 8 Apr 2009 17:59:08 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: <49D546F8.20807@gatworks.com> <49D693BA.8060909@gatworks.com> Message-ID: Hi Trent, I think I have hit on a work around but don't know why it works. The USB serial adapter is a "CableMAX" based on Prolific's PL2303. Backing out to the big picture, the application is old and has been very reliable until put on a new cpu and kernel. It only hangs sometimes say 25% and always at the same place, at tcdrain() on the flush() after the second write after startup. If it made it past this stage, all transmit and receive seemed reliable so it was like a startup timing issue. Since learning to debug kernel code is beyond my immediate priority, I took a shot at moving code around, adding delays, and such. I have found it good practice to do a flush after every write on streams like: outputStream.write(data.getBytes()); outputStream.flush(); If I remove the flush() after each write, the problem appears to go away! I don't think the flush is needed for a SerialOutputStream for this application anyway. Thanks for all the help, +BillJ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090408/35d96a9d/attachment-0011.html From bill7007 at gmail.com Thu Apr 9 09:20:11 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Thu, 9 Apr 2009 11:20:11 -0400 Subject: [Rxtx] Baud rate fixes in 2.2pre2 breaks 38400 on some Linux devices Message-ID: Hello, An application that worked at 38400 on a USB serial adapter (PL2303) using 2.1-7-r2 on Linux EL4 (and EL5) now fails using 2.2pre2. serialPort.setSerialPortParams(38400,SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); throws an unsupportedCommOperationException This problem matched a description of Bug 113and I posted a proposed patch there, but I don't understand the whole custom baud rate patch so it may need some thought. An older patch, [Rxtx] [Patch]: Baud Rate fixes try 1, testing encouraged., fixed some custom baud rates but apparently broke 38400 on some Linux device. Other baud rates seem to work OK. And, 38400 tested OK on local non-USB ports. My proposed patch probably breaks the custom baud rate patch since it was keyed on 38400 as a special case for Linux and my fix was to back out part of that patch, specifically: #if defined(TIOCGSERIAL) if ( cspeed == B38400 ) cspeed = 38400; #endif /* TIOCGSERIAL */ +BillJ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090409/5636af64/attachment-0010.html From cowwoc at bbs.darktech.org Fri Apr 10 08:38:49 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Fri, 10 Apr 2009 10:38:49 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: References: <49DB4212.40807@bbs.darktech.org> <49DC03BE.5010203@bbs.darktech.org> Message-ID: <49DF59F9.2050408@bbs.darktech.org> Doesn't Wikipedia list as an optional sub-system? Gili Trent Jarvi wrote: > > The support has been around for a long time to. I don't know the > details but the support appears to be tied to the OS. > > http://en.wikipedia.org/wiki/POSIX#POSIX_for_Windows > > On Tue, 7 Apr 2009, cowwoc wrote: > >> Trent Jarvi wrote: >>> I'm not sure what MSVC is using errno for but it should not be using >>> it except with POSIX extensions. Perhaps #undef is enough to get >>> rid of the warning and (maybe) has no ill consequences. Newer >>> windows have POSIX extensions that may show how Microsoft solved the >>> problem. >>> >>> It can probably fester. >> >> What does "newer windows" refer to in this case? I was compiling >> using Visual Studio 2008 sp1 under Windows Vista. Both are cutting >> edge technologies as far as official releases go. >> >> I think you're best suited to judge whether this warning is a big >> deal or not so I think you should see it for yourself. Please try >> firing up Visual Studio 2008 (express?) against the project I sent you. >> >> Gili >> From eranshuman at gmail.com Mon Apr 13 04:50:34 2009 From: eranshuman at gmail.com (Anshuman Srivastava) Date: Mon, 13 Apr 2009 16:20:34 +0530 Subject: [Rxtx] Send RTS /DTR signal Message-ID: <589913a50904130350n59cc51ffvbcd0a4eaefb4ce5f@mail.gmail.com> Hi, I want to send the RTS or DTR signal from the application Can anybody telll how to send the DTR /RTS signal using rxtxcomm libraries Thanks and regards -- Anshuman Srivastava "... in the end, it's not the years in your life that count. It's the life in your years." Buzz +91 9962515155 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090413/211b5ded/attachment-0007.html From ajmas at sympatico.ca Mon Apr 13 09:50:47 2009 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 13 Apr 2009 11:50:47 -0400 Subject: [Rxtx] Wiki Spam pages - need of captcha? Message-ID: Hi Trent, While checking for spam pages in the wiki I came across a page containing the following: "NOTICE: This page was created by a program as part of the Graffiti Network research project at Brown University. We have removed the data, but are unable to remove this page. We apologize for any inconveniences that our actions may have caused. For more information, please visit http://graffiti.cs.brown.edu/info/." Is there any chance we could add a captcha to account registration? Andr?-John From sguido at micromotive.net Mon Apr 13 09:46:15 2009 From: sguido at micromotive.net (Samuel Guido) Date: Mon, 13 Apr 2009 11:46:15 -0400 Subject: [Rxtx] Serial Output Stream Hangs on Windows Message-ID: <843C9F1C-72EE-4A40-B02A-3798EB0C57BF@micromotive.net> All, I am using RXTX in a small application to talk to a remote embedded device on a Windows host. All data is ASCII text. On physical comm ports, everything seems to be fine, messages are sent and received without much trouble. I am also trying to make the comm port selection automatic where I cycle through the available comm ports sending messages until I get the expected response. Unfortunately, when I query for the available comm ports, the bluetooth ports also show up. Whenever I try to send a string of characters to the bluetooth port, RXTX hangs way down in the call stack in the output stream, I believe in the DLL. I tried both the 2.1.7r2 and the 2.2pre2 releases and both have the same result. The send and receiving of messages from the comm port are in their own threads, but once the thread is blocked, I can't do anything with the comm ports since they are synchronized calls. The bluetooth ports are using a driver call "WIDCOMM" which I don't know who/what that is. This is on a IBM T42 laptop machine. Does anyone know what could be causing this? Is there a way to distinguish between bluetooth ports and physical comm ports? Please help, I am on a tight deadline and any help would greatly be appreciated. Thanks very much. Sam Guido From ajmas at sympatico.ca Mon Apr 13 11:04:24 2009 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 13 Apr 2009 13:04:24 -0400 Subject: [Rxtx] RxTX mentioned on Sun's Java Communications page Message-ID: Looks like RxTx gets some mention at Sun: Head over to the Java Communications page http://java.sun.com/products/javacomm/ and then click on Downloads and you get: " COMM API is a Java extension providing access to RS-232 serial ports and IEEE-1284 parallel ports (SPP mode). Sun Ray platform support is provided. Documentation and sample code are included, as well as interactive test utilities. API serial features provide access to: * Port settings (baud rate, parity, stop bits) * Port naming, mapping, enumeration (configurable) * Data transfer over TX, RX lines * DTR, CD, CTS, RTS and DSR signals * Hardware/Software flow-control * Receive-buffer threshold control * Asynchronous events indicating: * Data available on an RS-232 port * Port hardware line level changes * Port ownership changes within a JVM Update History: * javax.comm 3.0, Update 1 o Fixed problems locating and parsing portmap.conf * javax.comm 3.0, FCS o Redesigned portmapping and Sun Ray interoperability (see bundled documentation) * 2.0.3: o Added portmapping (comm.jar available 'as-is' for 3rd party native lib support)* Several Bugfixes to 2.0.3 (see bundled release notes) Note: Sun no longer offer's the Windows platform binaries of javax.comm, however javax.comm 2.0.3 can be used for the Windows platform, by using it in conjunction with the Win32 implementation layer provided by the RxTx project. To use that, download javax.comm for the 'generic' platform (which provides the front-end javax.comm API only, without platform specific back-end implementations bundled). Then acquire the Windows binary implementation rxtx-2.0.7pre1 from http://www.rxtx.org . " Looks like RxTx really is the closest thing we have to the 'official' implementation. From tjarvi at qbang.org Mon Apr 13 12:27:44 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 13 Apr 2009 12:27:44 -0600 (MDT) Subject: [Rxtx] RxTX mentioned on Sun's Java Communications page In-Reply-To: References: Message-ID: On Mon, 13 Apr 2009, Andre-John Mas wrote: > Looks like RxTx gets some mention at Sun: > > Head over to the Java Communications page http://java.sun.com/products/javacomm/ > and then click on Downloads and you get: > > " > COMM API is a Java extension providing access to RS-232 serial ports > and IEEE-1284 parallel ports (SPP mode). Sun Ray platform support is > provided. Documentation and sample code are included, as well as > interactive test utilities. API serial features provide access to: * > Port settings (baud rate, parity, stop bits) * Port naming, mapping, > enumeration (configurable) * Data transfer over TX, RX lines * DTR, > CD, CTS, RTS and DSR signals * Hardware/Software flow-control * > Receive-buffer threshold control * Asynchronous events indicating: * > Data available on an RS-232 port * Port hardware line level changes * > Port ownership changes within a JVM Update History: * javax.comm 3.0, > Update 1 o Fixed problems locating and parsing portmap.conf * > javax.comm 3.0, FCS o Redesigned portmapping and Sun Ray > interoperability (see bundled documentation) * 2.0.3: o Added > portmapping (comm.jar available 'as-is' for 3rd party native lib > support)* Several Bugfixes to 2.0.3 (see bundled release notes) Note: > Sun no longer offer's the Windows platform binaries of javax.comm, > however javax.comm 2.0.3 can be used for the Windows platform, by > using it in conjunction with the Win32 implementation layer provided > by the RxTx project. To use that, download javax.comm for the > 'generic' platform (which provides the front-end javax.comm API only, > without platform specific back-end implementations bundled). Then > acquire the Windows binary implementation rxtx-2.0.7pre1 from http://www.rxtx.org > .. > " > > Looks like RxTx really is the closest thing we have to the 'official' > implementation. Ugh. I don't know of any developer interest in maintaining rxtx 2.0. It would be cleaner for Sun to just openly take javax.comm for their Sun Ray project. If someone is interested in maintaining rxtx 2.0, don't be afraid to say so. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Mon Apr 13 16:04:19 2009 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 13 Apr 2009 17:04:19 -0500 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D8DDEB.5010908@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> Message-ID: <49E3B6E3.5050203@cox.net> cowwoc wrote: > Trent Jarvi wrote: >> You are responsible for cleaning up the serial ports when using threads. >> That said, if the thread did shut down, finalize should have been called >> if you are not passing the object around. See RXTXPort.java. >> >> protected void finalize() >> { >> if (debug) >> z.reportln( "RXTXPort:finalize()"); >> if( fd > 0 ) >> { >> if (debug) >> z.reportln( "RXTXPort:calling close()"); >> close(); >> } >> z.finalize(); >> } > > Two points: > > 1) One should never rely on finalizers because they may never run. A PhantomRef is the way to do this kind of cleanup in most cases. It will always fire. The real issue is that you have to understand that the on the Sun JVM, the GC can run finalization or advertise a dropped reference before an object is actually unreferenced in some cases. This happens, predominately in blocks of code where object references are short lived with no class member reference that the GC can find. When the JIT compiled code just references an object on the local stack and/or a register, the GC can prematurely attempt finalization/PhantomRef notification and result in bad things happening. The single solution to this problem is to use synchronize(obj){} at the end of the block of code that obj lives in, which keeps the object from getting reclaimed prematurely. For the sake of application sanity and recovery from erroneous code, it's almost always best to put resources like this into a map, accessed by name, and make an API method that lets you find the object by name, rather than by instance reference. Then, in your code, when you want to open a serial port, you'd do something like the following, which will close anything you already opened and then open it back up. Map ports = ...; public void closePort( String port ) { CommPort p = null; p = ports.remove(port); if( p != null ) p.close(); } public CommPort public CommPort openPort( String port, String user, int timeout ) throws IOException { closePort( port ); CommPort p = CommPortIdentifier.getPortIdentifier(port). open( user, timeout ); ports.put( port, p ); return p; } Appropriate use of synchronized(ports) may be necessary if ports is not referencing a concurrency safe Map implementation such as Hashtable or ConcurrentHashMap. Gregg Wonderly From gergg at cox.net Mon Apr 13 16:36:57 2009 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 13 Apr 2009 17:36:57 -0500 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: <49D546F8.20807@gatworks.com> <49D693BA.8060909@gatworks.com> Message-ID: <49E3BE89.4020402@cox.net> Check CTS/RTS and DTR/CD etc on the device to make sure you haven't hung the kernel trying to clean up something, but it's now waiting for CTS etc. In general, you should be careful about using HW flow control when cables can be trivially unplugged or broken. Use application layer checksums or similar things to make sure data that is flowing is sane and that buffers have not overrun, resulting in lost data. Gregg Wonderly Trent Jarvi wrote: > UTS_RELEASE is defined in now. The check really should > be removed from RXTX. It was a defensive check for wilder times when GNU > glibc did not have defines the kernel headers had so rxtx would include > the kernel headers instead. :/ > > If you don't have linux/version.h, it is generated when you configure the > kernel. make oldconfig used to do the trick. It may make sense to work > with the prerelease or CVS code. > > RXTX just assumes that flush, read and anything else the kernel exposes > may be called at anytime from any thread. There isn't a design for the > kernel interaction. There are higher level constraints put in Java to > prevent some things happening at the same time with 'synchronized.' > RXTXPort.java has all of those. > > When the port is opened, a native event thread is started which uses > select to know if an event has happened. > > BSD like systems have a native thread that fires off on write which tries > to flush() to determine when the output buffer is empty asynchronously. > > The rest is not marshaled in any fashion at the native level. T > > I think there is a lower level deadlock being triggered in flush as well. > I don't think it should be possible if everything was right underneath us. > You may want to examine the java code closer to make sure it isnt possible > the lock is there. > > > On Mon, 6 Apr 2009, Bill Johnson wrote: > >> Once it hung, three stack dumps minutes apart were exactly the same. >> I have a noticed that when it hangs, the read appears after flush() enter and >> before flush leave() that doesn't happen like: >> RXTXPort:SerialOutputStream:flush() enter >> RXTXPort:SerialInputStream:read(8192 0 8192) called >> >> When it works, flush() enter and leave happen together. It may just be because >> flush() hangs and read is the only other thread waiting to run at that point. >> I don't know much about the RXTX design and kernel interaction, just digging >> through the code some. Is there a design description somewhere? >> >> Am hung up on target system compile since UTS_RELEASE seems no longer defined for >> 2.6.18 up kernels and have not figured a good patch yet. But, that is another >> issue. >> >> Thanks for the good help. >> >> >> On Fri, Apr 3, 2009 at 6:54 PM, U. George wrote: >> I would have tried 2 or 3 "^\" . If things are stuck, then all will be >> at same 'java' instruction. If thread is moving, then one of the >> snapshots would be different. >> >> I *think* flushing/draining wont return until the kernel buffers to >> device have been accepted by device. Stuck/paused device? >> >> >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From cowwoc at bbs.darktech.org Mon Apr 13 20:41:20 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Mon, 13 Apr 2009 22:41:20 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49E3B6E3.5050203@cox.net> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49E3B6E3.5050203@cox.net> Message-ID: <49E3F7D0.5090207@bbs.darktech.org> Gregg Wonderly wrote: > A PhantomRef is the way to do this kind of cleanup in most cases. It > will always fire. The real issue is that you have to understand that > the on the Sun JVM, the GC can run finalization or advertise a dropped > reference before an object is actually unreferenced in some cases. This > happens, predominately in blocks of code where object references are > short lived with no class member reference that the GC can find. When > the JIT compiled code just references an object on the local stack > and/or a register, the GC can prematurely attempt > finalization/PhantomRef notification and result in bad things happening. I've never seen this myself. Can you reproduce it on the latest JRE? If so, this sounds like a bug to me and should be fixed. Please consider filing a bug report and telling me the bug number. I'll try running it by my Sun contacts. Gili From ferry_new2004 at yahoo.com Mon Apr 13 21:24:59 2009 From: ferry_new2004 at yahoo.com (Ferry Sumendap) Date: Mon, 13 Apr 2009 20:24:59 -0700 (PDT) Subject: [Rxtx] In Linux, RXTX serial port lib cannot send character which hex is more than 127. Message-ID: <30875.39589.qm@web33106.mail.mud.yahoo.com> Hello everybody, I have just tested the RXTXserial port library version RXTX2-1-7pre20 to send two characters which are character ascii 230 and 234. It seems that the driver somehow did not send the two characters into serial port if the Operating System is Linux Mandriva 2007 (kernel version 2.6.17-13mdv ) or Linux Mandriva 2009. I also tried the driver using same java code (java class file of the program I wrote), in Windows XP, it does work. Should I configure something (special configuration in Linux) or did I miss something ? I also have tested the latest RXTX 2.2pre2 driver, but it still have that problem. Regards, Ferry -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090413/94fdfbea/attachment-0006.html From tjarvi at qbang.org Mon Apr 13 22:01:04 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 13 Apr 2009 22:01:04 -0600 (MDT) Subject: [Rxtx] In Linux, RXTX serial port lib cannot send character which hex is more than 127. In-Reply-To: <30875.39589.qm@web33106.mail.mud.yahoo.com> References: <30875.39589.qm@web33106.mail.mud.yahoo.com> Message-ID: On Mon, 13 Apr 2009, Ferry Sumendap wrote: > Hello everybody, > > I have just tested the RXTXserial port library version? RXTX2-1-7pre20 to > send two characters which are character ascii? 230 and 234. It seems that > the driver somehow did not send the two characters into serial port if the > Operating System is Linux Mandriva 2007 (kernel version 2.6.17-13mdv > ) or Linux Mandriva 2009. > I also tried the driver using? same java code (java class file of the > program I wrote), in Windows XP,? it does work. > > Should I configure something (special configuration in Linux)? or did I miss > something ? > I also have tested the latest RXTX 2.2pre2 driver, but it still have that > problem. > Hello Ferry This sounds like an unlikely problem. Even with USB dongle issues, I can't think of a reason that would be a problem. Is this a connection at 9600 8N1? Sometimes it really is the cable. -- Trent Jarvi tjarvi at qbang.org From ferry_new2004 at yahoo.com Mon Apr 13 22:15:04 2009 From: ferry_new2004 at yahoo.com (Ferry Sumendap) Date: Mon, 13 Apr 2009 21:15:04 -0700 (PDT) Subject: [Rxtx] Fw: In Linux, RXTX serial port lib cannot send character which hex is more than 127. Message-ID: <948418.50805.qm@web33103.mail.mud.yahoo.com> ----- Forwarded Message ---- From: Ferry Sumendap To: Trent Jarvi Sent: Tuesday, April 14, 2009 11:10:04 AM Subject: Re: [Rxtx] In Linux, RXTX serial port lib cannot send character which hex is more than 127. Thank you for your answer. I use the same machine, cable and devices to test. My PC is installed with Linux Mandriva and WINDOWS. The serial port physically have no problem since using Windows, it works. I also tested the serial port using MONI (tcl based program). MONI is linux based program to send some characters to serial port. Using MONI, I sent the characters to /dev/ttyS0, and it works because the device which is plugged in /dev/ttyS0 received and answered the message. But for RXTX, some how, java based program cannot send those characters. With the same java based program, it works properly in WINDOWS and the same cable, devices, hardware specification. That's why I am curious about RXTX. Here is the serial port configuration I used. Com Port /dev/ttyS0 Baud rate 19200 Data bits 8 ( value = 8) Stop bits 1 ( value = 1) Parity None ( value = 0) Thank you very much for your response. Regards, Ferry ________________________________ From: Trent Jarvi To: Ferry Sumendap Cc: rxtx at qbang.org Sent: Tuesday, April 14, 2009 11:01:04 AM Subject: Re: [Rxtx] In Linux, RXTX serial port lib cannot send character which hex is more than 127. On Mon, 13 Apr 2009, Ferry Sumendap wrote: > Hello everybody, > > I have just tested the RXTXserial port library version RXTX2-1-7pre20 to > send two characters which are character ascii 230 and 234. It seems that > the driver somehow did not send the two characters into serial port if the > Operating System is Linux Mandriva 2007 (kernel version 2.6.17-13mdv > ) or Linux Mandriva 2009. > I also tried the driver using same java code (java class file of the > program I wrote), in Windows XP, it does work. > > Should I configure something (special configuration in Linux) or did I miss > something ? > I also have tested the latest RXTX 2.2pre2 driver, but it still have that > problem. > Hello Ferry This sounds like an unlikely problem. Even with USB dongle issues, I can't think of a reason that would be a problem. Is this a connection at 9600 8N1? Sometimes it really is the cable. -- Trent Jarvi tjarvi at qbang.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090413/27a37ea5/attachment-0006.html From ferry_new2004 at yahoo.com Mon Apr 13 22:23:53 2009 From: ferry_new2004 at yahoo.com (Ferry Sumendap) Date: Mon, 13 Apr 2009 21:23:53 -0700 (PDT) Subject: [Rxtx] In Linux, RXTX serial port lib cannot send character which hex is more than 127. In-Reply-To: References: <30875.39589.qm@web33106.mail.mud.yahoo.com> <81465.86461.qm@web33102.mail.mud.yahoo.com> Message-ID: <736778.48214.qm@web33108.mail.mud.yahoo.com> I am sorry not telling you about the configuration.. Yes I did test using the same serial port configuration, but the RXTX did not work properly. I also use "root" just in case there is security violation. If I sent another character that is below 127 (ascii < 127) the RXTX works properly either in LINUX or WINDOWS. I also cannot believe that coders of RXTX would make diffentiation between baudrate 19200 and 9600. The driver actually works very good unfortunately if the character is upper than ascii 127 (like ascii 230 and 234) it will not work. Thank you very much. Regards, Ferry ________________________________ From: Trent Jarvi To: Ferry Sumendap Cc: Trent Jarvi Sent: Tuesday, April 14, 2009 11:16:34 AM Subject: Re: [Rxtx] In Linux, RXTX serial port lib cannot send character which hex is more than 127. Hi Ferry, The only thing you mention that is not tested on a regular basis is the 19200 baudrate. There is nothing special (code wise) about that baudrate. On Mon, 13 Apr 2009, Ferry Sumendap wrote: > Thank you for your answer. > > I use the same machine, cable and devices to test. > My PC is installed with Linux Mandriva and WINDOWS. > The serial port physically have no problem since using Windows, it works. > > I also tested the serial port using MONI (tcl based program). > MONI is linux based program to send some characters to serial port. > Using MONI, I sent the characters to /dev/ttyS0, and it works because the > device which is plugged in /dev/ttyS0 received and answered the message. > > But for RXTX, some how, java based program cannot send those characters. > With the same java based program, it works properly in WINDOWS and the same > cable, devices, hardware specification. > That's why I am curious about RXTX. > > > > Here is the serial port configuration I used. > > Com Port /dev/ttyS0 > Baud rate 19200 > Data bits 8 ( value = 8) > Stop bits 1 ( value = 1) > Parity None ( value = 0) > > > > Thank you very much for your response. > > Regards, > Ferry > > > ____________________________________________________________________________ > From: Trent Jarvi > To: Ferry Sumendap > Cc: rxtx at qbang.org > Sent: Tuesday, April 14, 2009 11:01:04 AM > Subject: Re: [Rxtx] In Linux, RXTX serial port lib cannot send character > which hex is more than 127. > > > > On Mon, 13 Apr 2009, Ferry Sumendap wrote: > > > Hello everybody, > > > > I have just tested the RXTXserial port library version RXTX2-1-7pre20 to > > send two characters which are character ascii 230 and 234. It seems that > > the driver somehow did not send the two characters into serial port if the > > Operating System is Linux Mandriva 2007 (kernel version 2.6.17-13mdv > > ) or Linux Mandriva 2009. > > I also tried the driver using same java code (java class file of the > > program I wrote), in Windows XP, it does work. > > > > Should I configure something (special configuration in Linux) or did I > miss > > something ? > > I also have tested the latest RXTX 2.2pre2 driver, but it still have that > > problem. > > > > Hello Ferry > > This sounds like an unlikely problem. > > Even with USB dongle issues, I can't think of a reason that would be a > problem. Is this a connection at 9600 8N1? > > Sometimes it really is the cable. > > -- > Trent Jarvi > tjarvi at qbang.org > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090413/7a2fd5a0/attachment-0006.html From tjarvi at qbang.org Mon Apr 13 22:45:09 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 13 Apr 2009 22:45:09 -0600 (MDT) Subject: [Rxtx] In Linux, RXTX serial port lib cannot send character which hex is more than 127. In-Reply-To: <736778.48214.qm@web33108.mail.mud.yahoo.com> References: <30875.39589.qm@web33106.mail.mud.yahoo.com> <81465.86461.qm@web33102.mail.mud.yahoo.com> <736778.48214.qm@web33108.mail.mud.yahoo.com> Message-ID: This sounds like a signed vs unsigned char issue. Given that rxtx does binary read and write fine on Linux, I'm at a loss of what your problem may be. No, I don't suspect the baudrate is an issue either. On Mon, 13 Apr 2009, Ferry Sumendap wrote: > I am sorry not telling you about the configuration.. > > Yes I did test using the same serial port configuration, but the RXTX did > not work properly. > I also use "root" just in case there is security violation. > If? I sent another character that is below 127 (ascii < 127) the RXTX works > properly either in LINUX or WINDOWS. > > I also cannot believe that coders of RXTX would make diffentiation between > baudrate 19200 and 9600. > The driver actually works very good unfortunately if the character is upper > than ascii 127 (like ascii 230 and 234) it will not work. > > Thank you very much. > Regards, > > Ferry > > ____________________________________________________________________________ > From: Trent Jarvi > To: Ferry Sumendap > Cc: Trent Jarvi > Sent: Tuesday, April 14, 2009 11:16:34 AM > Subject: Re: [Rxtx] In Linux, RXTX serial port lib cannot send character > which hex is more than 127. > > > Hi Ferry, > > The only thing you mention that is not tested on a regular basis is the > 19200 baudrate.? There is nothing special (code wise) about that baudrate. > > On Mon, 13 Apr 2009, Ferry Sumendap wrote: > > > Thank you for your answer. > > > > I use the same machine, cable and devices to test. > > My PC is installed with Linux Mandriva and WINDOWS. > > The serial port physically have no problem since using Windows, it works. > > > > I also tested the serial port using MONI (tcl based program). > > MONI is linux based program to send some characters to serial port. > > Using MONI, I sent the characters to /dev/ttyS0, and it works because the > > device which is plugged in /dev/ttyS0 received and answered the message. > > > > But for RXTX, some how, java based program cannot send those characters. > > With the same java based program, it works properly in WINDOWS and the > same > > cable, devices, hardware specification. > > That's why I am curious about RXTX. > > > > > > > > Here is the serial port configuration I used. > > > > Com Port /dev/ttyS0 > > Baud rate 19200 > > Data bits 8 ( value = 8) > > Stop bits 1?? ( value = 1) > > Parity None? ( value = 0) > > > > > > > > Thank you very much for your response. > > > > Regards, > > Ferry > > > > > >___________________________________________________________________________ > _ > > From: Trent Jarvi > > To: Ferry Sumendap > > Cc: rxtx at qbang.org > > Sent: Tuesday, April 14, 2009 11:01:04 AM > > Subject: Re: [Rxtx] In Linux, RXTX serial port lib cannot send character > > which hex is more than 127. > > > > > > > > On Mon, 13 Apr 2009, Ferry Sumendap wrote: > > > > > Hello everybody, > > > > > > I have just tested the RXTXserial port library version? RXTX2-1-7pre20 > to > > > send two characters which are character ascii? 230 and 234. It seems > that > > > the driver somehow did not send the two characters into serial port if > the > > > Operating System is Linux Mandriva 2007 (kernel version 2.6.17-13mdv > > > ) or Linux Mandriva 2009. > > > I also tried the driver using? same java code (java class file of the > > > program I wrote), in Windows XP,? it does work. > > > > > > Should I configure something (special configuration in Linux)? or did I > > miss > > > something ? > > > I also have tested the latest RXTX 2.2pre2 driver, but it still have > that > > > problem. > > > > > > > Hello Ferry > > > > This sounds like an unlikely problem. > > > > Even with USB dongle issues, I can't think of a reason that would be a > > problem.? Is this a connection at 9600 8N1? > > > > Sometimes it really is the cable. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > > > > > > > > From ilkka at myller.com Mon Apr 13 23:12:16 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 14 Apr 2009 08:12:16 +0300 Subject: [Rxtx] In Linux, RXTX serial port lib cannot send character which hex is more than 127. In-Reply-To: References: <30875.39589.qm@web33106.mail.mud.yahoo.com> <81465.86461.qm@web33102.mail.mud.yahoo.com> <736778.48214.qm@web33108.mail.mud.yahoo.com> Message-ID: Hi, Another suggestion: incorrect java byte casting. Java byte type has a range from -128 to 127. I've seen people assume range of 0 - 255. Incorrect integer casting with bytes is a common mistake is to cause those >127 ascii issues. Could it be? (int)b versus (int)(b & 0xFF) -- I Trent Jarvi kirjoitti 14.4.2009 kello 7.45: > > This sounds like a signed vs unsigned char issue. Given that rxtx > does binary read and write fine on Linux, I'm at a loss of what your > problem may be. > > No, I don't suspect the baudrate is an issue either. > > On Mon, 13 Apr 2009, Ferry Sumendap wrote: > >> I am sorry not telling you about the configuration.. >> Yes I did test using the same serial port configuration, but the >> RXTX did >> not work properly. >> I also use "root" just in case there is security violation. >> If I sent another character that is below 127 (ascii < 127) the >> RXTX works >> properly either in LINUX or WINDOWS. >> I also cannot believe that coders of RXTX would make diffentiation >> between >> baudrate 19200 and 9600. >> The driver actually works very good unfortunately if the character >> is upper >> than ascii 127 (like ascii 230 and 234) it will not work. >> Thank you very much. >> Regards, >> Ferry >> ____________________________________________________________________________ >> From: Trent Jarvi >> To: Ferry Sumendap >> Cc: Trent Jarvi >> Sent: Tuesday, April 14, 2009 11:16:34 AM >> Subject: Re: [Rxtx] In Linux, RXTX serial port lib cannot send >> character >> which hex is more than 127. >> Hi Ferry, >> The only thing you mention that is not tested on a regular basis is >> the >> 19200 baudrate. There is nothing special (code wise) about that >> baudrate. >> On Mon, 13 Apr 2009, Ferry Sumendap wrote: >> > Thank you for your answer. >> > >> > I use the same machine, cable and devices to test. >> > My PC is installed with Linux Mandriva and WINDOWS. >> > The serial port physically have no problem since using Windows, >> it works. >> > >> > I also tested the serial port using MONI (tcl based program). >> > MONI is linux based program to send some characters to serial port. >> > Using MONI, I sent the characters to /dev/ttyS0, and it works >> because the >> > device which is plugged in /dev/ttyS0 received and answered the >> message. >> > >> > But for RXTX, some how, java based program cannot send those >> characters. >> > With the same java based program, it works properly in WINDOWS >> and the >> same >> > cable, devices, hardware specification. >> > That's why I am curious about RXTX. >> > >> > >> > >> > Here is the serial port configuration I used. >> > >> > Com Port /dev/ttyS0 >> > Baud rate 19200 >> > Data bits 8 ( value = 8) >> > Stop bits 1 ( value = 1) >> > Parity None ( value = 0) >> > >> > >> > >> > Thank you very much for your response. >> > >> > Regards, >> > Ferry >> > >> > >> > >> ___________________________________________________________________________ >> _ >> > From: Trent Jarvi >> > To: Ferry Sumendap >> > Cc: rxtx at qbang.org >> > Sent: Tuesday, April 14, 2009 11:01:04 AM >> > Subject: Re: [Rxtx] In Linux, RXTX serial port lib cannot send >> character >> > which hex is more than 127. >> > >> > >> > >> > On Mon, 13 Apr 2009, Ferry Sumendap wrote: >> > >> > > Hello everybody, >> > > >> > > I have just tested the RXTXserial port library version >> RXTX2-1-7pre20 >> to >> > > send two characters which are character ascii 230 and 234. It >> seems >> that >> > > the driver somehow did not send the two characters into serial >> port if >> the >> > > Operating System is Linux Mandriva 2007 (kernel version >> 2.6.17-13mdv >> > > ) or Linux Mandriva 2009. >> > > I also tried the driver using same java code (java class file >> of the >> > > program I wrote), in Windows XP, it does work. >> > > >> > > Should I configure something (special configuration in Linux) >> or did I >> > miss >> > > something ? >> > > I also have tested the latest RXTX 2.2pre2 driver, but it still >> have >> that >> > > problem. >> > > >> > >> > Hello Ferry >> > >> > This sounds like an unlikely problem. >> > >> > Even with USB dongle issues, I can't think of a reason that would >> be a >> > problem. Is this a connection at 9600 8N1? >> > >> > Sometimes it really is the cable. >> > >> > -- >> > Trent Jarvi >> > tjarvi at qbang.org >> > >> > >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From sunil at saltriver.com Tue Apr 14 01:06:38 2009 From: sunil at saltriver.com (Sunil Bhambani) Date: Tue, 14 Apr 2009 07:06:38 -0000 Subject: [Rxtx] RxTx on Mac for USB Message-ID: <1080422816.3127.6.camel@localhost.localdomain> Hi, I have a GPS device which is USB device. I want to use that device on Mac System and Java as the programming language. I have read that USB support through RxTx on Mac is not there. Is this correct? I would like to read the data that comes to GPS device. Can some connector be used to communicate with that device. For example USB to RJ11 or USB to serial connector? Are this connectors reliable enough to be used? Hope to get the reply soon. -- Thank & Regards Sunil -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090414/295ccb1d/attachment-0005.html From helgeingvart at gmail.com Tue Apr 14 01:43:04 2009 From: helgeingvart at gmail.com (Helge Fredriksen) Date: Tue, 14 Apr 2009 09:43:04 +0200 Subject: [Rxtx] IO exceptions on 2.2pre2 In-Reply-To: References: <306B677E-9207-44CB-81CD-787A50DB7DA6@myller.com> Message-ID: FYI: There seem to be success on this problem by switching to your commercial counterpart from SerialIO (http://www.serialio.com). A FTDI only problem? Best regards, Helge Fredriksen On Sat, Mar 28, 2009 at 5:32 PM, Helge Fredriksen wrote: > Thanks for your suggestions, > > We have tried switching off the power saving settings as recommended, but > regrettably we see the same things happening still. > > The FTDI device is not connected directly to USB hubs, no. > > Someone have any more ideas? > > Best regards, > Helge Fredriksen > > > On Tue, Mar 24, 2009 at 9:27 AM, Ilkka Myller wrote: > >> Hi Helge, >> >> I am not sure if this will help, but you could try this: >> >> echo on > /sys/bus/usb/devices//power/level >> echo 0 > /sys/bus/usb/devices//power/autosuspend >> >> is the USB-bus device id of your FTDI adapter (bus-device, for >> example "2-2") >> >> This will disable USB power saving/autosuspend of FTDI USB-device. >> I've seen some some systems where this helps with FTDI-adapter connection >> drops. >> >> Also: is your FTDI device directly connected to PC's USB root hub? If not, >> test that too. >> >> >> -- >> I >> >> (replace with the usb bus device id of your FTDI serial >> adapter) >> >> Helge Fredriksen kirjoitti 24.3.2009 kello 9.45: >> >> Hello! >> >> Here's the device details: >> >> FT232R is a USB to serial UART interface. >> >> Link to componentt: http://www.ftdichip.com/Products/FT232R.htm >> >> Regards, >> Helge Fredriksen >> >> On Tue, Mar 24, 2009 at 12:05 AM, Trent Jarvi wrote: >> >>> >>> >>> On Mon, 23 Mar 2009, Helge Fredriksen wrote: >>> >>> Hello again. >>>> >>>> I'm having a bit trouble with the 2.2pre2 version it seems. I'm having >>>> an >>>> application running on Ubuntu 8.10 that seem to run stable but after an >>>> hour >>>> or so the application breaks down with lot's of IO exceptions like this: >>>> >>>> java.io.IOException: Input/output error in nativeavailable >>>> at gnu.io.RXTXPort.nativeavailable(Native Method) >>>> at gnu.io.RXTXPort$SerialInputStream.available(RXTXPort.java:1596) >>>> >>>> atcom.poseidon.usb.UsbInterface$MySerialPortEventListener.serialEvent(UsbInte >>>> rface.java:251) >>>> at gnu.io.RXTXPort.sendEvent(RXTXPort.java:772) >>>> at gnu.io.RXTXPort.eventLoop(Native Method) >>>> at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1641) >>>> >>>> Any ideas? >>>> >>> >>> Hi Helge, >>> >>> It sounds like the file descriptor (USB driver) is in an invalid state. >>> >>> What can you tell us about the USB dongle? Is it bluetooth? Do you know >>> what chipset is in it? >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090414/e2c97c4f/attachment-0006.html From Steffen.DETTMER at ingenico.com Tue Apr 14 02:21:35 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 14 Apr 2009 10:21:35 +0200 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49E3F7D0.5090207@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49E3B6E3.5050203@cox.net> <49E3F7D0.5090207@bbs.darktech.org> Message-ID: <20090414082135.GG5090@elberon.bln.de.ingenico.com> * cowwoc wrote on Mon, Apr 13, 2009 at 22:41 -0400: > Gregg Wonderly wrote: > > The real issue is that you have to understand that > > the on the Sun JVM, the GC can run finalization or advertise a dropped > > reference before an object is actually unreferenced in some cases. > > I've never seen this myself. Can you reproduce it on the latest JRE? If > so, this sounds like a bug to me and should be fixed. Please consider > filing a bug report and telling me the bug number. I'll try running it > by my Sun contacts. I found some general hints here: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2261.html Traditional finalization in garbage collected languages is defined in terms of object reachability. But objects can easily become "unreachable" earlier than the programmer expects, due to compiler optimizations. An object may be logically in use long past the last point at which the memory associated with the object is accessed or referenced by any pointers visible to the garbage collector. In the worst case, the compiler might decide to store all the fields of an object in registers, and then observe that the "this" pointer for the newly allocated memory is dead immediately after the allocation, and hence not save it anywhere. The garbage collector, even if run immediately after the allocation, would then discover that the memory object is no longer reachable, and run the finalizer immediately, in spite of the fact that the object fields are still in use, and in fact may remain in use after the finalizer has run. However, if this would be a so general weakness that someone is adviced to store object instances in collections instead of using members or having the references on the stack - even if used correctly - I think it would be a major weakness which probably had been fixed, because otherwise raping collections as such workarounds would be commonly visible. BTW, I think the citation above is wrong if the optimised member values are used after that. The destructor / finalizer may set all fields to null or so and (ordinary) optimizers should not affect the behavior of correct and usual code I think. (ohh, and Cowwoc, forced-GC and to forbid the developer to control lifecycle in Java is considered a feature, not a bug! -- SCNR) oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From michael.erskine at ketech.com Tue Apr 14 02:50:53 2009 From: michael.erskine at ketech.com (Michael Erskine) Date: Tue, 14 Apr 2009 09:50:53 +0100 Subject: [Rxtx] Wiki Spam pages - need of captcha? In-Reply-To: References: Message-ID: <06BA3262D918014F9183B66425D5A8D45FA42D88FB@no-sv-03.ketech.local> All, See http://tech.slashdot.org/article.pl?sid=09/04/13/0120226 for details of this particular use of open wiki sites and the apology. Regards, Michael Erskine. From Steffen.DETTMER at ingenico.com Tue Apr 14 04:27:53 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 14 Apr 2009 12:27:53 +0200 Subject: [Rxtx] In Linux, RXTX serial port lib cannot send character which hex is more than 127. In-Reply-To: <30875.39589.qm@web33106.mail.mud.yahoo.com> References: <30875.39589.qm@web33106.mail.mud.yahoo.com> Message-ID: <20090414102753.GI5090@elberon.bln.de.ingenico.com> * Ferry Sumendap wrote on Mon, Apr 13, 2009 at 20:24 -0700: > I have just tested the RXTXserial port library version > RXTX2-1-7pre20 to send two characters which are character ascii > 230 and 234. Can you send -26 and -22 instead? Then it probably is a casting issue (as Trent and Ilkka already considered). oki, Steffen End of message. ------------------------------------------------------------------->8======= About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Bob_Jacobsen at lbl.gov Tue Apr 14 08:31:13 2009 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Tue, 14 Apr 2009 07:31:13 -0700 Subject: [Rxtx] RxTx on Mac for USB In-Reply-To: <1080422816.3127.6.camel@localhost.localdomain> References: <1080422816.3127.6.camel@localhost.localdomain> Message-ID: At 2:56 AM +0530 3/28/04, Sunil Bhambani wrote: >Hi, > >I have a GPS device which is USB device. I want to use that device >on Mac System and Java as the programming language. I have read that >USB support through RxTx on Mac is not there. Is this correct? I >would like to read the data that comes to GPS device. Can some >connector be used to communicate with that device. For example USB >to RJ11 or USB to serial connector? Are this connectors reliable >enough to be used? If the GPS device looks like a serial device to Mac OS X (Darwin), RXTX will work fine. To check: *) Unplug your device. *) Do the following command line, and keep the output: ls -lt /dev/ | head -10 *) Plug in your device and wait a couple seconds *) Repeat the above command line, and see if there are any new entries at the top of the output. The new entries, if any, are how your GPS device was mounted. If the new device(s) start with /dev/tty or /dev/cu, you'll be able to use RXTX. As a next step, you can use the "cu" command to try to talk to your GPS device as serial device. For example, cu -s 19200 -l /dev/tty.usbserial-LWPMMU13 You can download RXTX installers for various MacOS X version from here: But note these are for RXTX 2.0 versions (javax.comm package). Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From sunil at saltriver.com Wed Apr 15 00:06:40 2009 From: sunil at saltriver.com (Sunil Bhambani) Date: Wed, 15 Apr 2009 06:06:40 -0000 Subject: [Rxtx] RxTx on Mac for USB In-Reply-To: References: <1080422816.3127.6.camel@localhost.localdomain> Message-ID: <1080505612.2924.9.camel@localhost.localdomain> On Tue, 2009-04-14 at 07:31 -0700, Bob Jacobsen wrote: > At 2:56 AM +0530 3/28/04, Sunil Bhambani wrote: > >Hi, > > > >I have a GPS device which is USB device. I want to use that device > >on Mac System and Java as the programming language. I have read that > >USB support through RxTx on Mac is not there. Is this correct? I > >would like to read the data that comes to GPS device. Can some > >connector be used to communicate with that device. For example USB > >to RJ11 or USB to serial connector? Are this connectors reliable > >enough to be used? > > If the GPS device looks like a serial device to Mac OS X (Darwin), > RXTX will work fine. > > To check: > > *) Unplug your device. > *) Do the following command line, and keep the output: > > ls -lt /dev/ | head -10 > > *) Plug in your device and wait a couple seconds > > *) Repeat the above command line, and see if there are any new > entries at the top of the output. > > The new entries, if any, are how your GPS device was mounted. If the > new device(s) start with /dev/tty or /dev/cu, you'll be able to use > RXTX. > > As a next step, you can use the "cu" command to try to talk to your > GPS device as serial device. For example, > > cu -s 19200 -l /dev/tty.usbserial-LWPMMU13 > > You can download RXTX installers for various MacOS X version from here: > > > > But note these are for RXTX 2.0 versions (javax.comm package). > > Bob Hi Bob, I am using Mac 10.5 and I have done what you have said. I get the following output total 4 crw--w---- 1 Saltriver tty 16, 0 Apr 15 11:13 ttys000 crw-rw-rw- 1 root wheel 8, 0 Apr 15 11:13 random crw-rw-rw- 1 root tty 15, 1 Apr 15 11:13 ptmx crw------- 1 Saltriver staff 0, 0 Apr 15 11:10 console crw-rw-rw- 1 root wheel 3, 2 Apr 15 10:58 null crw------- 1 root wheel 23, 1 Apr 15 10:32 bpf1 crw------- 1 root wheel 23, 0 Apr 15 10:32 bpf0 crw------- 1 root wheel 11, 0 Apr 15 10:31 autofs crw------- 1 root wheel 17, 0 Apr 15 10:31 autofs_control saltriver-infosystemss-mac-mini:~ Saltriver$ ls -lt /dev/ | head -10 total 4 crw--w---- 1 Saltriver tty 16, 0 Apr 15 11:16 ttys000 crw-rw-rw- 1 root tty 15, 1 Apr 15 11:16 ptmx crw-rw-rw- 1 root wheel 8, 0 Apr 15 11:13 random crw------- 1 Saltriver staff 0, 0 Apr 15 11:10 console crw-rw-rw- 1 root wheel 3, 2 Apr 15 10:58 null crw------- 1 root wheel 23, 1 Apr 15 10:32 bpf1 crw------- 1 root wheel 23, 0 Apr 15 10:32 bpf0 crw------- 1 root wheel 11, 0 Apr 15 10:31 autofs crw------- 1 root wheel 17, 0 Apr 15 10:31 autofs_control I think the output is same in both. Is there any way of mounting that device. I am very new to Mac. I am using RXTX 2.1 without javax.comm package. I have tried the same code in fedora and it ran successfully. I have tried inserting pen drive in the USB port and it was detected. Hope to get a quick reply from you. Thanks & Regards Sunil -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090415/19e599e5/attachment-0004.html From Bob_Jacobsen at lbl.gov Wed Apr 15 03:43:26 2009 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Wed, 15 Apr 2009 02:43:26 -0700 Subject: [Rxtx] RxTx on Mac for USB In-Reply-To: <1080505612.2924.9.camel@localhost.localdomain> References: <1080422816.3127.6.camel@localhost.localdomain> <1080505612.2924.9.camel@localhost.localdomain> Message-ID: At 1:56 AM +0530 3/29/04, Sunil Bhambani wrote: > >I am using Mac 10.5 and I have done what you have said. I get the >following output > >total 4 >crw--w---- 1 Saltriver tty 16, 0 Apr 15 11:13 ttys000 >crw-rw-rw- 1 root wheel 8, 0 Apr 15 11:13 random >crw-rw-rw- 1 root tty 15, 1 Apr 15 11:13 ptmx >crw------- 1 Saltriver staff 0, 0 Apr 15 11:10 console ... >saltriver-infosystemss-mac-mini:~ Saltriver$ ls -lt /dev/ | head -10 >total 4 >crw--w---- 1 Saltriver tty 16, 0 Apr 15 11:16 ttys000 >crw-rw-rw- 1 root tty 15, 1 Apr 15 11:16 ptmx >crw-rw-rw- 1 root wheel 8, 0 Apr 15 11:13 random >crw------- 1 Saltriver staff 0, 0 Apr 15 11:10 console ... >I think the output is same in both. Is there any way of mounting that device. You're going to need a driver of some sort that will make the GPS unit appear as a serial device. > I am very new to Mac. I am using RXTX 2.1 without javax.comm package. This problem is happening before RXTX can do anything at all. Unless there's a device in /dev, RXTX can't even begin to be involved. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From cowwoc at bbs.darktech.org Wed Apr 15 09:08:21 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Wed, 15 Apr 2009 11:08:21 -0400 Subject: [Rxtx] RxTX mentioned on Sun's Java Communications page In-Reply-To: References: Message-ID: <49E5F865.1030206@bbs.darktech.org> >> Looks like RxTx really is the closest thing we have to the 'official' >> implementation. > > Ugh. I don't know of any developer interest in maintaining rxtx 2.0. It > would be cleaner for Sun to just openly take javax.comm for their Sun Ray > project. > > If someone is interested in maintaining rxtx 2.0, don't be afraid to say > so. Just curious, why not have the javax.comm layer just call gnu.io under the hood? This will make require no real work to maintain it even if the underlying implementation keeps on changing. From what I've seen so far the difference between the two APIs is minimal in most places. Gili From Kustaa.Nyholm at planmeca.com Wed Apr 15 09:42:33 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 15 Apr 2009 18:42:33 +0300 Subject: [Rxtx] Java5 support In-Reply-To: <49D7CD82.1040904@bbs.darktech.org> Message-ID: A recent post reminded me of this old thread that I do not think got any replies. Here is my take on the subject (of improving the API): Please do not 'improve' the API! Serial port is an old, simple and mature thing. Let's keep it that way. Very little will be gained by 'improving' it. It is already too bad that Sun spoiled the internals of javax.comm in version 3,0 so that the gnu.io package had to be coined. That is a nuisance but nothing compared to what happens if we start 'improve' the API and make it incompatible with Java Comm API. Even additions should be resisted as this will encourage people to write code that is not compatible with the 'standard' Java Comm API. The world does not need more standards but better compliance to existing standards. If someone feels things like generics/iterators for are needed it is simple to wrap the rxtx or java comm classes into classes to implement these new language features without changing the API. rxtx us great and many thanks and cudos to the maintainers and creators but it is lamentable that something this basic needs to be addressed outside standard JRE. Not to mention being able to do basic USB stuff in Java/std JRE in cross platform deployable fashion. br Kusti > From: cowwoc > Date: Sun, 5 Apr 2009 00:13:38 +0300 > To: > Conversation: [Rxtx] Java5 support > Subject: [Rxtx] Java5 support > > > > Now that you dropped javax.comm support, how about improving the API > by replacing Enumation by Iterator, int by enum, and using Generics? It > would improve the usability of the API. > > Gili > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From cowwoc at bbs.darktech.org Wed Apr 15 11:35:03 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Wed, 15 Apr 2009 13:35:03 -0400 Subject: [Rxtx] YACK Message-ID: <49E61AC7.2060701@bbs.darktech.org> Hi, Please increase the YACK() buffer size from 80 characters to 160. My long paths lead to the following kinds of errors: Error 0x5 at c:\users\gili\documents\rxtx\rxtx-devel\src\termios.c(892): AccessError 0x5 at c:\users\gili\documents\rxtx\rxtx-devel\src\termios.c(892): Access Thanks, Gili From talberts at msiscales.com Wed Apr 15 12:22:20 2009 From: talberts at msiscales.com (Tim Alberts) Date: Wed, 15 Apr 2009 11:22:20 -0700 Subject: [Rxtx] RxTX mentioned on Sun's Java Communications page In-Reply-To: <49E5F865.1030206@bbs.darktech.org> References: <49E5F865.1030206@bbs.darktech.org> Message-ID: <49E625DC.80509@msiscales.com> cowwoc wrote: >>> Looks like RxTx really is the closest thing we have to the 'official' >>> implementation. >>> >> Ugh. I don't know of any developer interest in maintaining rxtx 2.0. It >> would be cleaner for Sun to just openly take javax.comm for their Sun Ray >> project. >> >> If someone is interested in maintaining rxtx 2.0, don't be afraid to say >> so. >> > > Just curious, why not have the javax.comm layer just call gnu.io under > the hood? This will make require no real work to maintain it even if the > underlying implementation keeps on changing. From what I've seen so far > the difference between the two APIs is minimal in most places. > > Gili I can't help but get in on this discussion thread. I starting using javax.comm from Sun and I've got a huge project that is entirely based on it now. Sun dropped support for windows which is a huge disappointment for me. I read Sun's page that if you want serial ports on Java with Windows, go to RXTX. I did this. In my experiments I've found by trial and error (and by discussion on this list) that under the hood, Sun javax.comm and RXTX gnu.io are completely different. So since Sun doesn't care about anyone who doesn't use their platforms (or at least anyone that uses Windows). I would argue that RXTX has no obligation to Sun. On another note, I have yet to see (or get) RXTX to work in my code that works perfectly fine using the old Sun javax.comm for windows binaries that I am forced to continue to run on. -------------- next part -------------- A non-text attachment was scrubbed... Name: talberts.vcf Type: text/x-vcard Size: 337 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20090415/a373e7f2/attachment-0004.vcf From cowwoc at bbs.darktech.org Wed Apr 15 13:13:03 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Wed, 15 Apr 2009 15:13:03 -0400 Subject: [Rxtx] Java5 support In-Reply-To: References: Message-ID: <49E631BF.9040501@bbs.darktech.org> > > A recent post reminded me of this old thread that I do not think got any > replies. > > Here is my take on the subject (of improving the API): > > Please do not 'improve' the API! > > Serial port is an old, simple and mature thing. Let's keep it that way. > Very little will be gained by 'improving' it. It is already too bad > that Sun spoiled the internals of javax.comm in version 3,0 so that the > gnu.io package had to be coined. That is a nuisance but nothing compared to > what happens if we start 'improve' the API and make it incompatible with > Java Comm API. > > Even additions should be resisted as this will encourage people to write > code that is not compatible with the 'standard' Java Comm API. The world > does not need more standards but better compliance to existing standards. > > If someone feels things like generics/iterators for are needed it is simple > to wrap the rxtx or java comm classes into classes to implement these > new language features without changing the API. > > rxtx us great and many thanks and cudos to the maintainers and creators but > it is lamentable that something this basic needs to be addressed outside > standard JRE. Not to mention being able to do basic USB stuff in Java/std > JRE in cross platform deployable fashion. > > br Kusti Hi Kusti, I must be missing something... I thought the entire point of forking off gnu.io was to innovate the API in a different direction than javax.comm, otherwise why wouldn't you stick to the standard API? Thanks, Gili From cowwoc at bbs.darktech.org Wed Apr 15 14:57:46 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Wed, 15 Apr 2009 16:57:46 -0400 Subject: [Rxtx] Timeout patch Message-ID: <49E64A4A.1050806@bbs.darktech.org> Hi, Please review the attached patch. - fixes disableReceiveTimeout() so reads now block until data is available. - receive timeouts and threshold handling is now more consistent across all implementations Gili -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: timeout.patch Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20090415/6815e522/attachment-0004.pl From bschlining at gmail.com Wed Apr 15 17:15:10 2009 From: bschlining at gmail.com (Brian Schlining) Date: Wed, 15 Apr 2009 16:15:10 -0700 Subject: [Rxtx] Timeout patch In-Reply-To: <49E64A4A.1050806@bbs.darktech.org> References: <49E64A4A.1050806@bbs.darktech.org> Message-ID: > > - fixes disableReceiveTimeout() so reads now block until data is available. Finally!! Thanks for submitting this patch. Hopefully it'll be integrated soon. Cheers -- B ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090415/a4143da7/attachment-0004.html From tristan.dyer at cgi.com Wed Apr 15 17:32:43 2009 From: tristan.dyer at cgi.com (Dyer, Tristan) Date: Wed, 15 Apr 2009 19:32:43 -0400 Subject: [Rxtx] Java5 support In-Reply-To: <49E631BF.9040501@bbs.darktech.org> References: <49E631BF.9040501@bbs.darktech.org> Message-ID: <9DA32B4D8579AF44AD96C1CC2E9C518D0346E9EB@MTL-MSG-02.cgiclients.com> That's weird. All I had to do to get my project running on RxTx was to change javax.comm to gnu.io I assume the reason for the fork to gnu.io was precisely to preserve compatibility with javax.comm. Unless Sun is willing to give you a TCK (or someone wants to pay for it) you wouldn't be able to provide any of the "new" javax.comm 3.0 feature set to windows and call it javax.comm, and as a side effect you get to keep the api consistent across platforms as well. Apache has been in a pissing fight with Sun for a couple years about this in regards to Harmony. As I remember rxtx was a lower level that suns CommAPI jar could talk to, to provide javax.comm on linux originally. With sun only providing CommAPI for some environments it became necessary to fork. At least that's how I assume it got here. Tristan -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of cowwoc Sent: Wednesday, April 15, 2009 4:13 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Java5 support > > A recent post reminded me of this old thread that I do not think got any > replies. > > Here is my take on the subject (of improving the API): > > Please do not 'improve' the API! > > Serial port is an old, simple and mature thing. Let's keep it that way. > Very little will be gained by 'improving' it. It is already too bad > that Sun spoiled the internals of javax.comm in version 3,0 so that the > gnu.io package had to be coined. That is a nuisance but nothing compared to > what happens if we start 'improve' the API and make it incompatible with > Java Comm API. > > Even additions should be resisted as this will encourage people to write > code that is not compatible with the 'standard' Java Comm API. The world > does not need more standards but better compliance to existing standards. > > If someone feels things like generics/iterators for are needed it is simple > to wrap the rxtx or java comm classes into classes to implement these > new language features without changing the API. > > rxtx us great and many thanks and cudos to the maintainers and creators but > it is lamentable that something this basic needs to be addressed outside > standard JRE. Not to mention being able to do basic USB stuff in Java/std > JRE in cross platform deployable fashion. > > br Kusti Hi Kusti, I must be missing something... I thought the entire point of forking off gnu.io was to innovate the API in a different direction than javax.comm, otherwise why wouldn't you stick to the standard API? Thanks, Gili _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Apr 15 17:48:20 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 15 Apr 2009 17:48:20 -0600 (MDT) Subject: [Rxtx] Timeout patch In-Reply-To: <49E64A4A.1050806@bbs.darktech.org> References: <49E64A4A.1050806@bbs.darktech.org> Message-ID: On Wed, 15 Apr 2009, cowwoc wrote: > Hi, > > Please review the attached patch. > > - fixes disableReceiveTimeout() so reads now block until data is available. > - receive timeouts and threshold handling is now more consistent across all > implementations > Hi Gili, This looks good to me. One 'minor' issue is that you are returning -1 instead of 0 now on timeout. It is fair to say timeouts are the same as the end of input but that is new behavior in rxtx we should warn existing users about so they can adjust their code. -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Wed Apr 15 17:52:46 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Wed, 15 Apr 2009 19:52:46 -0400 Subject: [Rxtx] Timeout patch In-Reply-To: References: <49E64A4A.1050806@bbs.darktech.org> Message-ID: <49E6734E.4010809@bbs.darktech.org> Actually returning -1 on timeout would be bug on my part. I believe that InputStream is expecting us to return 0 in such a case. Which part of my patch changes the return value? Thanks, Gili Trent Jarvi wrote: > On Wed, 15 Apr 2009, cowwoc wrote: > >> Hi, >> >> Please review the attached patch. >> >> - fixes disableReceiveTimeout() so reads now block until data is >> available. >> - receive timeouts and threshold handling is now more consistent >> across all implementations >> > > Hi Gili, > > This looks good to me. One 'minor' issue is that you are returning -1 > instead of 0 now on timeout. It is fair to say timeouts are the same as > the end of input but that is new behavior in rxtx we should warn > existing users about so they can adjust their code. > > -- > Trent Jarvi > tjarvi at qbang.org > From tjarvi at qbang.org Wed Apr 15 18:38:01 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 15 Apr 2009 18:38:01 -0600 (MDT) Subject: [Rxtx] Java5 support In-Reply-To: <9DA32B4D8579AF44AD96C1CC2E9C518D0346E9EB@MTL-MSG-02.cgiclients.com> References: <49E631BF.9040501@bbs.darktech.org> <9DA32B4D8579AF44AD96C1CC2E9C518D0346E9EB@MTL-MSG-02.cgiclients.com> Message-ID: The project isn't interested in breaking projects or changing the API. That said, we do allow some extensions to be added that are clearly marked as such. These extensions are all in the weird science category - they are not alternatives to doing what the API can already do or even something many people would want to use some of the time. The gnu.io namespace is used to avoid polluting of the javax.comm namespace. There are a number of reasons why we could be concerned about using javax.comm including political and/or legal questions but the main reason is a project like rxtx should do no harm. On Wed, 15 Apr 2009, Dyer, Tristan wrote: > That's weird. > > All I had to do to get my project running on RxTx was to change > javax.comm to gnu.io > > I assume the reason for the fork to gnu.io was precisely to preserve > compatibility with javax.comm. Unless Sun is willing to give you a TCK > (or someone wants to pay for it) you wouldn't be able to provide any of > the "new" javax.comm 3.0 feature set to windows and call it javax.comm, > and as a side effect you get to keep the api consistent across platforms > as well. Apache has been in a pissing fight with Sun for a couple years > about this in regards to Harmony. > > As I remember rxtx was a lower level that suns CommAPI jar could talk > to, to provide javax.comm on linux originally. With sun only providing > CommAPI for some environments it became necessary to fork. > > At least that's how I assume it got here. > > Tristan > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > Of cowwoc > Sent: Wednesday, April 15, 2009 4:13 PM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Java5 support > >> >> A recent post reminded me of this old thread that I do not think got > any >> replies. >> >> Here is my take on the subject (of improving the API): >> >> Please do not 'improve' the API! >> >> Serial port is an old, simple and mature thing. Let's keep it that > way. >> Very little will be gained by 'improving' it. It is already too bad >> that Sun spoiled the internals of javax.comm in version 3,0 so that > the >> gnu.io package had to be coined. That is a nuisance but nothing > compared to >> what happens if we start 'improve' the API and make it incompatible > with >> Java Comm API. >> >> Even additions should be resisted as this will encourage people to > write >> code that is not compatible with the 'standard' Java Comm API. The > world >> does not need more standards but better compliance to existing > standards. >> >> If someone feels things like generics/iterators for are needed it is > simple >> to wrap the rxtx or java comm classes into classes to implement these >> new language features without changing the API. >> >> rxtx us great and many thanks and cudos to the maintainers and > creators but >> it is lamentable that something this basic needs to be addressed > outside >> standard JRE. Not to mention being able to do basic USB stuff in > Java/std >> JRE in cross platform deployable fashion. >> >> br Kusti > > Hi Kusti, > > I must be missing something... I thought the entire point of forking > > off gnu.io was to innovate the API in a different direction than > javax.comm, otherwise why wouldn't you stick to the standard API? > > Thanks, > Gili > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Wed Apr 15 18:53:42 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 15 Apr 2009 18:53:42 -0600 (MDT) Subject: [Rxtx] Timeout patch In-Reply-To: <49E6734E.4010809@bbs.darktech.org> References: <49E64A4A.1050806@bbs.darktech.org> <49E6734E.4010809@bbs.darktech.org> Message-ID: Hi Gili, I guess the documentation just needs to be clear and consistant (which it really wasn't before). This is what caught my eye but looking above it, I see the previous documentation mentions -1 in places too. -*timeout threshold Behavior -*------------------------------------------------------------------------ -*0 0 blocks until 1 byte is available -*>0 0 blocks until timeout occurs, returns 0 on timeout -*>0 >0 blocks until timeout or reads threshold bytes, - returns 0 on timeout -*0 >0 blocks until reads threshold bytes - */ + * timeout threshold Behavior + * --------------------------------------------------------------------------- + * < 0 <= 0 blocks until any data is available. + * < 0 > 0 blocks until {@code min(threshold, b.len)} bytes are available. + * >=0 <=0 blocks for {@code timeout} ms or until any data is available. Returns -1 on timeout. + * >=0 > 0 blocks for {@code timeout} ms or until {@code min(threshold, b.len)} bytes are available. Returns -1 on timeout. On Wed, 15 Apr 2009, cowwoc wrote: > > Actually returning -1 on timeout would be bug on my part. I believe > that InputStream is expecting us to return 0 in such a case. Which part of my > patch changes the return value? > > Thanks, > Gili > > Trent Jarvi wrote: >> On Wed, 15 Apr 2009, cowwoc wrote: >> >>> Hi, >>> >>> Please review the attached patch. >>> >>> - fixes disableReceiveTimeout() so reads now block until data is >>> available. >>> - receive timeouts and threshold handling is now more consistent across >>> all implementations >>> >> >> Hi Gili, >> >> This looks good to me. One 'minor' issue is that you are returning -1 >> instead of 0 now on timeout. It is fair to say timeouts are the same as >> the end of input but that is new behavior in rxtx we should warn existing >> users about so they can adjust their code. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> > From cowwoc at bbs.darktech.org Wed Apr 15 19:26:28 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Wed, 15 Apr 2009 21:26:28 -0400 Subject: [Rxtx] Timeout patch In-Reply-To: References: <49E64A4A.1050806@bbs.darktech.org> <49E6734E.4010809@bbs.darktech.org> Message-ID: <49E68944.3050808@bbs.darktech.org> Hi Trent, Please modify the Javadoc to read that timeouts will return 0. PS: The rxtx source contains plenty of ... questionable ... lines of code. The following items come to mind: 1) In serial_read() we return -1 on various error codes instead of throwing the appropriate exception back into the Java layer. 2) Some Java methods print error messages to stdout instead of throwing exceptions on invalid input. 3) #ifdef LIFE_IS_GOOD (is this ever used?) and "/* Baby did a bad baad thing */". Ifdef and comments like this litter the code. 4) Most files use C-language instead of C++. I am not advocating fancy C++ but rather C code wrapped in objects. Moving variable declarations closer to their usage and perhaps grouping related methods into cohesive classes would improve readability. I know this is an open-source project, but the quality of the code freaks me out :) Is there any resistance to fixing some of these problems? Gili Trent Jarvi wrote: > > Hi Gili, > > I guess the documentation just needs to be clear and consistant (which > it really wasn't before). This is what caught my eye but looking > above it, I see the previous documentation mentions -1 in places too. > > -*timeout threshold Behavior > -*------------------------------------------------------------------------ > > -*0 0 blocks until 1 byte is available > -*>0 0 blocks until timeout occurs, returns 0 on timeout > -*>0 >0 blocks until timeout or reads threshold bytes, > - returns 0 on timeout > -*0 >0 blocks until reads threshold bytes > - */ > + * timeout threshold Behavior > + * > --------------------------------------------------------------------------- > > + * < 0 <= 0 blocks until any data is available. > + * < 0 > 0 blocks until {@code min(threshold, > b.len)} bytes are available. > + * >=0 <=0 blocks for {@code timeout} ms or until > any data is available. Returns -1 on timeout. > + * >=0 > 0 blocks for {@code timeout} ms or until > {@code min(threshold, b.len)} bytes are available. Returns -1 on timeout. > > > > On Wed, 15 Apr 2009, cowwoc wrote: > >> >> Actually returning -1 on timeout would be bug on my part. I >> believe that InputStream is expecting us to return 0 in such a case. >> Which part of my patch changes the return value? >> >> Thanks, >> Gili >> >> Trent Jarvi wrote: >>> On Wed, 15 Apr 2009, cowwoc wrote: >>> >>>> Hi, >>>> >>>> Please review the attached patch. >>>> >>>> - fixes disableReceiveTimeout() so reads now block until data is >>>> available. >>>> - receive timeouts and threshold handling is now more consistent >>>> across all implementations >>>> >>> >>> Hi Gili, >>> >>> This looks good to me. One 'minor' issue is that you are returning >>> -1 instead of 0 now on timeout. It is fair to say timeouts are the >>> same as the end of input but that is new behavior in rxtx we should >>> warn existing users about so they can adjust their code. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >> From cowwoc at bbs.darktech.org Wed Apr 15 19:30:08 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Wed, 15 Apr 2009 21:30:08 -0400 Subject: [Rxtx] Java5 support In-Reply-To: References: <49E631BF.9040501@bbs.darktech.org> <9DA32B4D8579AF44AD96C1CC2E9C518D0346E9EB@MTL-MSG-02.cgiclients.com> Message-ID: <49E68A20.80209@bbs.darktech.org> Trent Jarvi wrote: > The project isn't interested in breaking projects or changing the API. > That said, we do allow some extensions to be added that are clearly marked > as such. These extensions are all in the weird science category - they > are not alternatives to doing what the API can already do or even > something many people would want to use some of the time. We could define rxtx-specific classes in gnu.io that extend those in javax.comm so users would enjoy both backwards compatibility as well as rxtx-specific extensions. > The gnu.io namespace is used to avoid polluting of the javax.comm > namespace. There are a number of reasons why we could be concerned about > using javax.comm including political and/or legal questions but the main > reason is a project like rxtx should do no harm. Did anyone from Sun \take issue with the aforementioned approach (gnu.io extending javax.comm)? Gili > On Wed, 15 Apr 2009, Dyer, Tristan wrote: > >> That's weird. >> >> All I had to do to get my project running on RxTx was to change >> javax.comm to gnu.io >> >> I assume the reason for the fork to gnu.io was precisely to preserve >> compatibility with javax.comm. Unless Sun is willing to give you a TCK >> (or someone wants to pay for it) you wouldn't be able to provide any of >> the "new" javax.comm 3.0 feature set to windows and call it javax.comm, >> and as a side effect you get to keep the api consistent across platforms >> as well. Apache has been in a pissing fight with Sun for a couple years >> about this in regards to Harmony. >> >> As I remember rxtx was a lower level that suns CommAPI jar could talk >> to, to provide javax.comm on linux originally. With sun only providing >> CommAPI for some environments it became necessary to fork. >> >> At least that's how I assume it got here. >> >> Tristan >> >> >> -----Original Message----- >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >> Of cowwoc >> Sent: Wednesday, April 15, 2009 4:13 PM >> To: rxtx at qbang.org >> Subject: Re: [Rxtx] Java5 support >> >>> A recent post reminded me of this old thread that I do not think got >> any >>> replies. >>> >>> Here is my take on the subject (of improving the API): >>> >>> Please do not 'improve' the API! >>> >>> Serial port is an old, simple and mature thing. Let's keep it that >> way. >>> Very little will be gained by 'improving' it. It is already too bad >>> that Sun spoiled the internals of javax.comm in version 3,0 so that >> the >>> gnu.io package had to be coined. That is a nuisance but nothing >> compared to >>> what happens if we start 'improve' the API and make it incompatible >> with >>> Java Comm API. >>> >>> Even additions should be resisted as this will encourage people to >> write >>> code that is not compatible with the 'standard' Java Comm API. The >> world >>> does not need more standards but better compliance to existing >> standards. >>> If someone feels things like generics/iterators for are needed it is >> simple >>> to wrap the rxtx or java comm classes into classes to implement these >>> new language features without changing the API. >>> >>> rxtx us great and many thanks and cudos to the maintainers and >> creators but >>> it is lamentable that something this basic needs to be addressed >> outside >>> standard JRE. Not to mention being able to do basic USB stuff in >> Java/std >>> JRE in cross platform deployable fashion. >>> >>> br Kusti >> Hi Kusti, >> >> I must be missing something... I thought the entire point of forking >> >> off gnu.io was to innovate the API in a different direction than >> javax.comm, otherwise why wouldn't you stick to the standard API? >> >> Thanks, >> Gili >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Apr 15 20:19:01 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 15 Apr 2009 20:19:01 -0600 (MDT) Subject: [Rxtx] Timeout patch In-Reply-To: <49E68944.3050808@bbs.darktech.org> References: <49E64A4A.1050806@bbs.darktech.org> <49E6734E.4010809@bbs.darktech.org> <49E68944.3050808@bbs.darktech.org> Message-ID: Hi Gili, Your glowing review obviously means you have not read termios.c :) I'm not against the type of changes like you suggest. I do think they will need bake time and we have people waiting for what we have now. Putting proactive changes in the following release would be fine. The returning -1 issues are wrong and should be fixed. We can do that now. Regarding C/C++, I think the best thing to do for this project is push as much logic as is possible out of the C files and into Java. Use Java for the objects and C to perform as little as possible. This is a compromise in a sense; C++ is perfectly fine and would work. C++ could even be easier to read and probably would avoid some bugs - especial with C strings. I really don't want to build g++ cross compilers for all the platforms we do in the ToyBox. In practice, adding g++ into the mix is an order of magnitude harder to get working. If we can avoid using C++ completely, there is a measurable advantage in what we can easily deliver. http://rxtx.qbang.org//ToyBox Proof of concept: http://rxtx.qbang.org/ToyBox/2.1-7-build1/Linux/glibc-2.3.5/ On Wed, 15 Apr 2009, cowwoc wrote: > Hi Trent, > > Please modify the Javadoc to read that timeouts will return 0. > > PS: The rxtx source contains plenty of ... questionable ... lines of code. > The following items come to mind: > > 1) In serial_read() we return -1 on various error codes instead of throwing > the appropriate exception back into the Java layer. > 2) Some Java methods print error messages to stdout instead of throwing > exceptions on invalid input. > 3) #ifdef LIFE_IS_GOOD (is this ever used?) and "/* Baby did a bad baad > thing */". Ifdef and comments like this litter the code. > 4) Most files use C-language instead of C++. I am not advocating fancy C++ > but rather C code wrapped in objects. Moving variable declarations closer to > their usage and perhaps grouping related methods into cohesive classes would > improve readability. > > I know this is an open-source project, but the quality of the code > freaks me out :) Is there any resistance to fixing some of these problems? > > Gili > > Trent Jarvi wrote: >> >> Hi Gili, >> >> I guess the documentation just needs to be clear and consistant (which it >> really wasn't before). This is what caught my eye but looking above it, I >> see the previous documentation mentions -1 in places too. >> >> -*timeout threshold Behavior >> -*------------------------------------------------------------------------ >> -*0 0 blocks until 1 byte is available >> -*>0 0 blocks until timeout occurs, returns 0 on timeout >> -*>0 >0 blocks until timeout or reads threshold bytes, >> - returns 0 on timeout >> -*0 >0 blocks until reads threshold bytes >> - */ >> + * timeout threshold Behavior >> + * >> --------------------------------------------------------------------------- >> + * < 0 <= 0 blocks until any data is available. >> + * < 0 > 0 blocks until {@code min(threshold, b.len)} >> bytes are available. >> + * >=0 <=0 blocks for {@code timeout} ms or until any >> data is available. Returns -1 on timeout. >> + * >=0 > 0 blocks for {@code timeout} ms or until {@code >> min(threshold, b.len)} bytes are available. Returns -1 on timeout. >> >> >> >> On Wed, 15 Apr 2009, cowwoc wrote: >> >>> >>> Actually returning -1 on timeout would be bug on my part. I believe >>> that InputStream is expecting us to return 0 in such a case. Which part of >>> my patch changes the return value? >>> >>> Thanks, >>> Gili >>> >>> Trent Jarvi wrote: >>>> On Wed, 15 Apr 2009, cowwoc wrote: >>>> >>>>> Hi, >>>>> >>>>> Please review the attached patch. >>>>> >>>>> - fixes disableReceiveTimeout() so reads now block until data is >>>>> available. >>>>> - receive timeouts and threshold handling is now more consistent across >>>>> all implementations >>>>> >>>> >>>> Hi Gili, >>>> >>>> This looks good to me. One 'minor' issue is that you are returning -1 >>>> instead of 0 now on timeout. It is fair to say timeouts are the same as >>>> the end of input but that is new behavior in rxtx we should warn existing >>>> users about so they can adjust their code. >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> >>> > From tjarvi at qbang.org Wed Apr 15 21:38:29 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 15 Apr 2009 21:38:29 -0600 (MDT) Subject: [Rxtx] Java5 support In-Reply-To: <49E68A20.80209@bbs.darktech.org> References: <49E631BF.9040501@bbs.darktech.org> <9DA32B4D8579AF44AD96C1CC2E9C518D0346E9EB@MTL-MSG-02.cgiclients.com> <49E68A20.80209@bbs.darktech.org> Message-ID: On Wed, 15 Apr 2009, cowwoc wrote: > Trent Jarvi wrote: >> The project isn't interested in breaking projects or changing the API. That >> said, we do allow some extensions to be added that are clearly marked as >> such. These extensions are all in the weird science category - they are >> not alternatives to doing what the API can already do or even something >> many people would want to use some of the time. > > We could define rxtx-specific classes in gnu.io that extend those in > javax.comm so users would enjoy both backwards compatibility as well as > rxtx-specific extensions. > >> The gnu.io namespace is used to avoid polluting of the javax.comm >> namespace. There are a number of reasons why we could be concerned about >> using javax.comm including political and/or legal questions but the main >> reason is a project like rxtx should do no harm. > > Did anyone from Sun \take issue with the aforementioned approach > (gnu.io extending javax.comm)? > It would take more than an opinion from someone at Sun before we moved like that. javax.comm (a namespace grandfathered into the JSR) is a broken namespace with a special 'generic' legacy release that may be discontinued at any time. The people using rxtx are interested in what javax.comm was in version 2.0. Not the 3.0 currently offered which appears to be a quick fix for a business need Sun satisfied on Solaris. Why would we ever depend upon (extend) this namespace? -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Thu Apr 16 10:38:42 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Thu, 16 Apr 2009 12:38:42 -0400 Subject: [Rxtx] Java5 support In-Reply-To: References: <49E631BF.9040501@bbs.darktech.org> <9DA32B4D8579AF44AD96C1CC2E9C518D0346E9EB@MTL-MSG-02.cgiclients.com> <49E68A20.80209@bbs.darktech.org> Message-ID: <49E75F12.7010603@bbs.darktech.org> Trent Jarvi wrote: > It would take more than an opinion from someone at Sun before we moved > like that. > > javax.comm (a namespace grandfathered into the JSR) is a broken > namespace with a special 'generic' legacy release that may be > discontinued at any time. The people using rxtx are interested in what > javax.comm was in version 2.0. Not the 3.0 currently offered which > appears to be a quick fix for a business need Sun satisfied on Solaris. > > Why would we ever depend upon (extend) this namespace? I was under the impression that javax.comm 3.0 was backwards compatible against 2.0... What changes in 3.0 do the rxtx folk object to? The way I see it, gnu.io suffers from the following pain points: 1) Not backwards compatible with standard API 2) Non-existent Javadoc for most of the API 3) Tiny community base, non-existent commercial support, questionable code quality. I still don't understand enough about the reasoning behind the namespace fork. I'm all for forking if we take the opportunity to innovate the API, but if you're going to keep it almost identical I'd be in favor of just having gnu.io extend javax.comm. Again, I might change my mind once I understand your reasoning better but that's how I feel now. Gili From bschlining at gmail.com Thu Apr 16 12:04:05 2009 From: bschlining at gmail.com (Brian Schlining) Date: Thu, 16 Apr 2009 11:04:05 -0700 Subject: [Rxtx] Java5 support In-Reply-To: <49E75F12.7010603@bbs.darktech.org> References: <49E631BF.9040501@bbs.darktech.org> <9DA32B4D8579AF44AD96C1CC2E9C518D0346E9EB@MTL-MSG-02.cgiclients.com> <49E68A20.80209@bbs.darktech.org> <49E75F12.7010603@bbs.darktech.org> Message-ID: > > > I was under the impression that javax.comm 3.0 was backwards > compatible > against 2.0... What changes in 3.0 do the rxtx folk object to? I haven't tried 3.0, since my target platforms are usually Mac or Windows. I can say that when Sun dropped Windows support of Javacomm, it was quite a slap in the face. The real kicker was that they removed the downloads for version 2.0 too. So that left folks who were using Sun's API in a pickle. > > The way I see it, gnu.io suffers from the following pain points: > > 1) Not backwards compatible with standard API Hmmm, not exactly true. When Sun removed Javacomm 2.0, RXTX was a real savior, I only had to change the namespace in my code and everything worked. > 2) Non-existent Javadoc for most of the API Sort of. Since RXTX's API is the same as Sun's, code examples and Javadocs from Sun's stuff do apply to RXTX. > 3) Tiny community base, non-existent commercial support, questionable > code quality. You really should back those assertions up with facts before make them. I can think of a number of projects here at my employer that use RXTX, so we really appreciate Trent's work as well as all the folks who have contributed patches. If you want commercial support I'm sure that if you offered enough money, Trent would work something out with you ;-). Also, there's always http://serialio.com/products/serialport/serialport.php As to the code quality, the project is open source, feel free to contribute fixes. > I still don't understand enough about the reasoning behind the > namespace fork. I'm all for forking if we take the opportunity to > innovate the API, but if you're going to keep it almost identical I'd be > in favor of just having gnu.io extend javax.comm. Again, I might change > my mind once I understand your reasoning better but that's how I feel now. > As to extending/innovating the API, RXTX is an open-source project. You can always take the code base and fork it to suit your needs, as long as you adhere to the LGPL license. Cheers -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090416/32cb4447/attachment-0003.html From paul at cometway.com Thu Apr 16 12:56:35 2009 From: paul at cometway.com (Paul Cunningham) Date: Thu, 16 Apr 2009 14:56:35 -0400 Subject: [Rxtx] Java5 support Message-ID: <91BF244D-07E4-4B30-9F9D-0DC0964045B4@cometway.com> I've been a steady lurker on this board for years and have to agree with Brian here: 1) RXTX was a savior -- long before javax.comm was dropped from Sun's repertoire. For Mac OS X users it's the ONLY option. Serial port support on the Mac has always been a sore spot for me. 2) There's nothing complicated about the javax.comm APIs and they are well Javadoc'ed all over the web. RXTX adherence to them has been very consistent. 3) RS-232 with Java is a tiny community period. If you are reading this, I'm sorry but you are a freak. Anyone doing RS-232 for unknown device "x" is a member of an even tinier community with practically no support whatsoever. However this RXTX list community is extremely well supported and every important question is addressed quickly, personally and in great detail by Trent himself. You can't get support like that from most "commercial" operations and we certainly never got that from commercial entities like Sun. Nobody here is going to hold your hand, but we will point you to any available resources that aren't already clearly spelled out on the RXTX page. You might have to learn how to download and build the package for yourself to get the latest updates and fixes, but that's just par for the course. -pc On Apr 16, 2009, at 2:04 PM, Brian Schlining wrote: > > I was under the impression that javax.comm 3.0 was backwards > compatible > against 2.0... What changes in 3.0 do the rxtx folk object to? > > I haven't tried 3.0, since my target platforms are usually Mac or > Windows. I can say that when Sun dropped Windows support of > Javacomm, it was quite a slap in the face. The real kicker was that > they removed the downloads for version 2.0 too. So that left folks > who were using Sun's API in a pickle. > > > The way I see it, gnu.io suffers from the following pain > points: > > 1) Not backwards compatible with standard API > > Hmmm, not exactly true. When Sun removed Javacomm 2.0, RXTX was a > real savior, I only had to change the namespace in my code and > everything worked. > > 2) Non-existent Javadoc for most of the API > > Sort of. Since RXTX's API is the same as Sun's, code examples and > Javadocs from Sun's stuff do apply to RXTX. > > 3) Tiny community base, non-existent commercial support, questionable > code quality. > > You really should back those assertions up with facts before make > them. > > I can think of a number of projects here at my employer that use > RXTX, so we really appreciate Trent's work as well as all the folks > who have contributed patches. If you want commercial support I'm > sure that if you offered enough money, Trent would work something > out with you ;-). Also, there's always http://serialio.com/products/serialport/serialport.php > > As to the code quality, the project is open source, feel free to > contribute fixes. > > I still don't understand enough about the reasoning behind the > namespace fork. I'm all for forking if we take the opportunity to > innovate the API, but if you're going to keep it almost identical > I'd be > in favor of just having gnu.io extend javax.comm. Again, I might > change > my mind once I understand your reasoning better but that's how I > feel now. > > As to extending/innovating the API, RXTX is an open-source project. > You can always take the code base and fork it to suit your needs, as > long as you adhere to the LGPL license. > > Cheers > > -- > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > Brian Schlining > bschlining at gmail.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090416/dd8eda0b/attachment-0003.html From cowwoc at bbs.darktech.org Thu Apr 16 14:07:41 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Thu, 16 Apr 2009 16:07:41 -0400 Subject: [Rxtx] Java5 support In-Reply-To: <91BF244D-07E4-4B30-9F9D-0DC0964045B4@cometway.com> References: <91BF244D-07E4-4B30-9F9D-0DC0964045B4@cometway.com> Message-ID: <49E7900D.3060100@bbs.darktech.org> Paul Cunningham wrote: > 2) There's nothing complicated about the javax.comm APIs and they are > well Javadoc'ed all over the web. RXTX adherence to them has been very > consistent. The fact that javax.comm has good Javadoc does not mean that gnu.io does. The latter has little or no Javadoc. Yes we could assume that gnu.io's documentation is identical to javax.comm but the fact remains that code-completion won't bring up Javadoc for gnu.io. Secondly, someone mentioned recently that although the APIs are supposed to be the same, RXTX in fact behaves noticeably different from javax.comm. The gnu.io specification needs to be nailed down one way or the other. Gili From bschlining at gmail.com Thu Apr 16 14:25:38 2009 From: bschlining at gmail.com (Brian Schlining) Date: Thu, 16 Apr 2009 13:25:38 -0700 Subject: [Rxtx] Java5 support In-Reply-To: <49E7900D.3060100@bbs.darktech.org> References: <91BF244D-07E4-4B30-9F9D-0DC0964045B4@cometway.com> <49E7900D.3060100@bbs.darktech.org> Message-ID: > > The fact that javax.comm has good Javadoc does not mean that gnu.io > does. The latter has little or no Javadoc. Yes we could assume that > gnu.io's documentation is identical to javax.comm but the fact remains > that code-completion won't bring up Javadoc for gnu.io. Gili, perhaps a highly motivated person, such as yourself, could fill in the Javadocs and contribute the patches back to RXTX? -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090416/79502619/attachment-0003.html From cowwoc at bbs.darktech.org Thu Apr 16 14:47:27 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Thu, 16 Apr 2009 16:47:27 -0400 Subject: [Rxtx] Java5 support In-Reply-To: References: <91BF244D-07E4-4B30-9F9D-0DC0964045B4@cometway.com> <49E7900D.3060100@bbs.darktech.org> Message-ID: <49E7995F.1020304@bbs.darktech.org> Brian, I have already submitted two patches for RXTX in the past week alone... I understand that Sun's decision to drop Windows and Mac support angered quite a few people but I fail to see the link between the reference implementation (which angered you) and the specification (which by all accounts is great). Why not extend their specification and completely replace the implementation? From what I've read, javax.comm 3.0's API is completely backwards compatible to 2.0. On the flip side, if you're not interested in extending javax.comm, why not refactor the gnu.io package to improve usability and I would be more than happy to contribute a completely new Javadoc. Gili Brian Schlining wrote: > The fact that javax.comm has good Javadoc does not mean that > gnu.io > does. The latter has little or no Javadoc. Yes we could assume that > gnu.io 's documentation is identical to javax.comm > but the fact remains > that code-completion won't bring up Javadoc for gnu.io . > > > Gili, perhaps a highly motivated person, such as yourself, could fill in > the Javadocs and contribute the patches back to RXTX? > > -- > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > Brian Schlining > bschlining at gmail.com From talberts at msiscales.com Thu Apr 16 14:55:50 2009 From: talberts at msiscales.com (Tim Alberts) Date: Thu, 16 Apr 2009 13:55:50 -0700 Subject: [Rxtx] RXTX Simple Demo Program Message-ID: <49E79B56.5010604@msiscales.com> I don't think it exists yet, so I'd like to propose it be done. I would like to see a demo program that opens a serial port and allows transmitting/receiving of data and configuration of ports via the RXTX gnu.io software. One of the features that was driving me to move to RXTX (aside from Sun dropping support), was the upcoming ability to use web install. I have not kept up so I'm not sure yet if that is implemented, but if/when it is, a demo program to distribute via web install would be outstanding to see from RXTX. I know that Sun has (had) a blackbox demo program that tries to open every available serial port it finds on the computer and allows for transmit/receive and configuration of the serial port. This is pretty much what I have in mind for RXTX. Is this a reasonable request? -------------- next part -------------- A non-text attachment was scrubbed... Name: talberts.vcf Type: text/x-vcard Size: 337 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20090416/3986518c/attachment-0003.vcf From tjarvi at qbang.org Thu Apr 16 14:56:35 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Apr 2009 14:56:35 -0600 (MDT) Subject: [Rxtx] Java5 support In-Reply-To: <49E7900D.3060100@bbs.darktech.org> References: <91BF244D-07E4-4B30-9F9D-0DC0964045B4@cometway.com> <49E7900D.3060100@bbs.darktech.org> Message-ID: On Thu, 16 Apr 2009, cowwoc wrote: > Paul Cunningham wrote: >> 2) There's nothing complicated about the javax.comm APIs and they are >> well Javadoc'ed all over the web. RXTX adherence to them has been very >> consistent. > > The fact that javax.comm has good Javadoc does not mean that gnu.io > does. The latter has little or no Javadoc. Yes we could assume that > gnu.io's documentation is identical to javax.comm but the fact remains > that code-completion won't bring up Javadoc for gnu.io. Secondly, > someone mentioned recently that although the APIs are supposed to be the > same, RXTX in fact behaves noticeably different from javax.comm. The > gnu.io specification needs to be nailed down one way or the other. > Hi Gili RXTX treats the javax.comm v2.0 API docs as the truth. When rxtx does not behave like the docs say, we treat it as a bug. If the bug really bothers someone, they fix it. That said, there will be behavior differences between the implementations. RXTX is not a 'bug per bug' implementation of javax.comm. Many default settings are not documented and can differ also. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Apr 16 15:47:24 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Apr 2009 15:47:24 -0600 (MDT) Subject: [Rxtx] Java5 support In-Reply-To: <49E7995F.1020304@bbs.darktech.org> References: <91BF244D-07E4-4B30-9F9D-0DC0964045B4@cometway.com> <49E7900D.3060100@bbs.darktech.org> <49E7995F.1020304@bbs.darktech.org> Message-ID: On Thu, 16 Apr 2009, cowwoc wrote: > On the flip side, if you're not interested in extending javax.comm, why > not refactor the gnu.io package to improve usability and I would be more > than happy to contribute a completely new Javadoc. Hi Gili, Changing the API to use the latest offerings in JREs is not in itself a good reason to break an API. If the functionality is there, this library is better off not changing because many applications count on that API remaining stable. If you have some usability issues that hold merit beyond your personal preferences and make sense to most of the people here, RXTX can change if it is obviously the right thing to do. -- Trent Jarvi tjarvi at qbang.org From paul at cometway.com Thu Apr 16 15:52:18 2009 From: paul at cometway.com (Paul Cunningham) Date: Thu, 16 Apr 2009 17:52:18 -0400 Subject: [Rxtx] Java5 support In-Reply-To: <49E7900D.3060100@bbs.darktech.org> References: <91BF244D-07E4-4B30-9F9D-0DC0964045B4@cometway.com> <49E7900D.3060100@bbs.darktech.org> Message-ID: <9146C76F-17D8-468D-A0F2-CAC9512BCDD6@cometway.com> Code completion... isn't that where you stub out some methods, check it into CVS, and the next day find out that someone else finished your work? ;-) Seemingly your project has exposed RXTX to more finicky devices than the ones I have worked with. I can understand why better Javadocs would be useful if you are using IDEs as a tool to learn and remember your APIs, and you sound qualified enough to contribute information about the kinds of idiosyncrasies between javax.comm and gui.io to the RXTX project. I also understand that you have read the javax.comm 3.0 APIs and are upset that no one has actually implemented them. An updated specification and your keen interest in seeing it implemented is apparently not enough to make that happen in a world where RS-232 is only used for legacy support of devices with no hope for firmware updates. -pc On Apr 16, 2009, at 4:07 PM, cowwoc wrote: > Paul Cunningham wrote: >> 2) There's nothing complicated about the javax.comm APIs and they >> are well Javadoc'ed all over the web. RXTX adherence to them has >> been very consistent. > > The fact that javax.comm has good Javadoc does not mean that gnu.io > does. The latter has little or no Javadoc. Yes we could assume that > gnu.io's documentation is identical to javax.comm but the fact > remains that code-completion won't bring up Javadoc for gnu.io. > Secondly, someone mentioned recently that although the APIs are > supposed to be the same, RXTX in fact behaves noticeably different > from javax.comm. The gnu.io specification needs to be nailed down > one way or the other. > > Gili > > From paul at cometway.com Thu Apr 16 16:14:16 2009 From: paul at cometway.com (Paul Cunningham) Date: Thu, 16 Apr 2009 18:14:16 -0400 Subject: [Rxtx] Java5 support In-Reply-To: <9146C76F-17D8-468D-A0F2-CAC9512BCDD6@cometway.com> References: <91BF244D-07E4-4B30-9F9D-0DC0964045B4@cometway.com> <49E7900D.3060100@bbs.darktech.org> <9146C76F-17D8-468D-A0F2-CAC9512BCDD6@cometway.com> Message-ID: <47F476E8-5F95-4521-A437-11622583210F@cometway.com> btw, i mean no disrespect to anyone actively developing an RS-232 interfaces for new devices. in fact my most recent project involved a freescale chip using a UART- to-USB chip, as i have no idea how to go about interfacing USB devices to Java. RXTX behaved very well, even when the USB driver didn't. is there anything resembling javax.comm for USB? -pc On Apr 16, 2009, at 5:52 PM, Paul Cunningham wrote: > in a world where RS-232 is > only used for legacy support of devices with no hope for firmware > updates. From tjarvi at qbang.org Thu Apr 16 16:50:12 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Apr 2009 16:50:12 -0600 (MDT) Subject: [Rxtx] Java5 support In-Reply-To: <47F476E8-5F95-4521-A437-11622583210F@cometway.com> References: <91BF244D-07E4-4B30-9F9D-0DC0964045B4@cometway.com> <49E7900D.3060100@bbs.darktech.org> <9146C76F-17D8-468D-A0F2-CAC9512BCDD6@cometway.com> <47F476E8-5F95-4521-A437-11622583210F@cometway.com> Message-ID: Hi Paul, JSR 80 is USB HID support. http://javax-usb.org/ http://jcp.org/aboutJava/communityprocess/final/jsr080/index.html On Thu, 16 Apr 2009, Paul Cunningham wrote: > btw, i mean no disrespect to anyone actively developing an RS-232 > interfaces for new devices. > > in fact my most recent project involved a freescale chip using a UART- > to-USB chip, as i have no idea how to go about interfacing USB devices > to Java. RXTX behaved very well, even when the USB driver didn't. > > is there anything resembling javax.comm for USB? -pc > > > On Apr 16, 2009, at 5:52 PM, Paul Cunningham wrote: > >> in a world where RS-232 is >> only used for legacy support of devices with no hope for firmware >> updates. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From cowwoc at bbs.darktech.org Thu Apr 16 16:57:43 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Thu, 16 Apr 2009 18:57:43 -0400 Subject: [Rxtx] Java5 support In-Reply-To: References: <91BF244D-07E4-4B30-9F9D-0DC0964045B4@cometway.com> <49E7900D.3060100@bbs.darktech.org> <9146C76F-17D8-468D-A0F2-CAC9512BCDD6@cometway.com> <47F476E8-5F95-4521-A437-11622583210F@cometway.com> Message-ID: <49E7B7E7.9050302@bbs.darktech.org> Last time I looked this, there was no usable Windows version. Gili Trent Jarvi wrote: > Hi Paul, > > JSR 80 is USB HID support. > > http://javax-usb.org/ > http://jcp.org/aboutJava/communityprocess/final/jsr080/index.html > > On Thu, 16 Apr 2009, Paul Cunningham wrote: > >> btw, i mean no disrespect to anyone actively developing an RS-232 >> interfaces for new devices. >> >> in fact my most recent project involved a freescale chip using a UART- >> to-USB chip, as i have no idea how to go about interfacing USB devices >> to Java. RXTX behaved very well, even when the USB driver didn't. >> >> is there anything resembling javax.comm for USB? -pc >> >> >> On Apr 16, 2009, at 5:52 PM, Paul Cunningham wrote: >> >>> in a world where RS-232 is >>> only used for legacy support of devices with no hope for firmware >>> updates. >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Apr 16 17:02:49 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Apr 2009 17:02:49 -0600 (MDT) Subject: [Rxtx] RXTX Simple Demo Program In-Reply-To: <49E79B56.5010604@msiscales.com> References: <49E79B56.5010604@msiscales.com> Message-ID: On Thu, 16 Apr 2009, Tim Alberts wrote: > I don't think it exists yet, so I'd like to propose it be done. I would like > to see a demo program that opens a serial port and allows > transmitting/receiving of data and configuration of ports via the RXTX gnu.io > software. > > One of the features that was driving me to move to RXTX (aside from Sun > dropping support), was the upcoming ability to use web install. I have not > kept up so I'm not sure yet if that is implemented, but if/when it is, a demo > program to distribute via web install would be outstanding to see from RXTX. > > I know that Sun has (had) a blackbox demo program that tries to open every > available serial port it finds on the computer and allows for > transmit/receive and configuration of the serial port. This is pretty much > what I have in mind for RXTX. > > Is this a reasonable request? > Hi Tim, It is a great request. I don't know if anyone will write tha application though. We could include it with rxtx as a demo like BlackBox was with Sun's commapi. But.. You can run Sun's BlackBox source code through the ChangePackage.sh and use BlackBox with rxtx 2.1/2.2 for personal use. ChangePackage.sh is in the contrib directory with the rxtx source code. As I recall, there was just one minor modification required - BlackBox had a hard coded number of ports which could cause problems. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Apr 16 20:25:29 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Apr 2009 20:25:29 -0600 (MDT) Subject: [Rxtx] Timeout patch In-Reply-To: <49E64A4A.1050806@bbs.darktech.org> References: <49E64A4A.1050806@bbs.darktech.org> Message-ID: On Wed, 15 Apr 2009, cowwoc wrote: > Hi, > > Please review the attached patch. > > - fixes disableReceiveTimeout() so reads now block until data is available. > - receive timeouts and threshold handling is now more consistent across all > implementations > Attached is the core change to serial Gili has suggested. I ran tests that cover about 40% of the serial code without regressions. If you happen to use the same 40%, you are safe :) Otherwise, I suggest trying the changes. I'd like to hear if this fixes issues for anyone. I put some binaries for win32, Mac and linux32 here: ftp://ftp.qbang.org/pub/rxtx/test-timeout.zip Unfortunately, The original patch tries to do several things. Some of the changes are not correct and require further review. This is just the timeout portion for serial code which I've reviewed and tested. -- Trent Jarvi tjarvi at qbang.org -------------- next part -------------- Index: src/SerialImp.c =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v retrieving revision 1.46.2.203 diff -u -r1.46.2.203 SerialImp.c --- src/SerialImp.c 19 Mar 2009 03:27:48 -0000 1.46.2.203 +++ src/SerialImp.c 17 Apr 2009 02:05:48 -0000 @@ -3298,6 +3298,8 @@ if (vtime < 0){ timeout = 0; + if (threshold <= 0) + threshold = 1; } else if (vtime == 0){ timeout = 1; Index: src/gnu/io/RXTXPort.java =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/gnu/io/RXTXPort.java,v retrieving revision 1.27.2.76 diff -u -r1.27.2.76 RXTXPort.java --- src/gnu/io/RXTXPort.java 13 Nov 2008 23:37:45 -0000 1.27.2.76 +++ src/gnu/io/RXTXPort.java 17 Apr 2009 02:05:48 -0000 @@ -1,7 +1,7 @@ /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. -| Copyright 1997-2008 by Trent Jarvi tjarvi at qbang.org and others who +| Copyright 1997-2009 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at @@ -398,19 +398,16 @@ { if (debug) z.reportln( "RXTXPort:enableReceiveTimeout() called"); - if( time >= 0 ) - { - timeout = time; - NativeEnableReceiveTimeoutThreshold( time , threshold, - InputBuffer ); - } - else + if( time < 0 ) { throw new IllegalArgumentException ( "Unexpected negative timeout value" ); } + timeout = time; + NativeEnableReceiveTimeoutThreshold( timeout , threshold, + InputBuffer ); if (debug) z.reportln( "RXTXPort:enableReceiveTimeout() returning"); } @@ -444,19 +441,16 @@ { if (debug) z.reportln( "RXTXPort:enableReceiveThreshold( " + thresh + " ) called"); - if(thresh >=0) - { - threshold=thresh; - NativeEnableReceiveTimeoutThreshold(timeout, threshold, - InputBuffer); - } - else /* invalid thresh */ + if(thresh < 1) { throw new IllegalArgumentException ( - "Unexpected negative threshold value" + "Threshold value must be possitive" ); } + threshold=thresh; + NativeEnableReceiveTimeoutThreshold(timeout, threshold, + InputBuffer); if (debug) z.reportln( "RXTXPort:enableReceiveThreshold( " + thresh + " ) returned"); } @@ -465,8 +459,12 @@ public void disableReceiveThreshold() { if (debug) - z.reportln( "RXTXPort:disableReceiveThreshold() called and returning"); - enableReceiveThreshold(0); + z.reportln( "RXTXPort:disableReceiveThreshold(0) called"); + threshold = 0; + NativeEnableReceiveTimeoutThreshold(timeout, threshold, + InputBuffer); + if (debug) + z.reportln( "RXTXPort:disableReceiveThreshold(0) returning"); } /** * @return int the recieve threshold @@ -1415,7 +1413,7 @@ */ int Minimum = len; - if( threshold==0 ) + if( threshold < 1 ) { /* * If threshold is disabled, read should return as soon @@ -1528,7 +1526,7 @@ */ int Minimum = len; - if( threshold==0 ) + if( threshold < 1 ) { /* * If threshold is disabled, read should return as soon From cowwoc at bbs.darktech.org Thu Apr 16 23:09:03 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Fri, 17 Apr 2009 01:09:03 -0400 Subject: [Rxtx] Problems with read timeout In-Reply-To: References: <49E64A4A.1050806@bbs.darktech.org> Message-ID: <49E80EEF.6000503@bbs.darktech.org> I've been playing with the read timeout behavior and I'm seeing some non-intuitive behavior. I've got an endless loop that does the following: 1) COM1 and COM2 are connected to one another. They are opened at 300 baud, with read timeout of 300ms. 2) COM1 writes "CONNECTION" 3) COM2 reads "CONNECTION" 4) COM2 writes "CONNECTION 9600 8 NONE 1 RTS/CTS" and tries a read operation. 5) COM1 receives "CONNECTION 960" when suddenly COM2 hits the 300ms read timeout. COM2 gets an IOException (caused by the timeout), and closes the serial port. 6) COM1 never gets the full message because the connection was closed in middle of sending. I want step 4 to block until COM1 receives the full message before it attempts the read operation but I'm not sure how to achieve this. I was somewhat expecting the write() or flush() operation to block until the send was complete... Any ideas? Gili From Steffen.DETTMER at ingenico.com Fri Apr 17 03:55:01 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 17 Apr 2009 11:55:01 +0200 Subject: [Rxtx] Java5 support In-Reply-To: <49E7900D.3060100@bbs.darktech.org> References: <91BF244D-07E4-4B30-9F9D-0DC0964045B4@cometway.com> <49E7900D.3060100@bbs.darktech.org> Message-ID: <20090417095501.GL13774@elberon.bln.de.ingenico.com> Hi, I cannot resist to make some comments, too :) In short, I think rxtx and gnu.io are good. Even if the API is `accidently' the same as javax.comm, logically rxtx IMHO is independent. It offers functionality an application can use - it does not need javax.comm at all. - IMHO Javadoc of javax.comm is /not/ good. What does it help to document `DATABITS_5' with `5 data bit format'? The documentation of SerialPort to me looks like what a less interested, less motivated student would write after failing a code review because of lack of documentation (review of course will fail again, even worse, because identifier <-> microdoc redundancy :)) There are so many issues with the docs... Also, those `optional functionality' is IMHO just a design bug. An interface is to define the interface, the features and functions that are available. Now Java has interfaces with optional functions. loooooooooool This ends that you have an application using this interface correctly and having a correct implementation of this interface but they do not work together because in fact they are using a different interface. It was hidden to the compiler by using `optional methods'. Just great. - namespace gnu.io IMHO is correct (well, don't know if gnu is correct etc, I just mean different from javax is) namespaces are exactly invented for such cases. Maybe gnu.io could implement javax.comm interfaces, maybe not. If someone really has a problem with package names, why not simply perl -npi -e 's/gnu.io/javax.comm/g' *.java could be some rule in some Makefile. - Some `wrapper' adding usability to the Java APIs (like InputStream) IMHO is essential and required anyway. I dislike the APIs, for instance InputStream and those. It is almost impossible to write really correct code with it. It is sufficient for simple GUI stuff you can kill if it blocks or so, but for e.g. server applications IMHO it is not sufficient. Timeouts are needed and so on. Well, this would just lead to a API discussion which would be a different topic. Because a wrapper is needed, package namings IMHO are no issue. Personally, I would prefer for some future version to drop the logical dependency to the stange javax.comm.SerialPort thingy, instead have a clean simple but specific JNI interface. This is `an implementation detail', so rxtx can do whatever is appropriate :) - this java event and multi-threading mixes IMHO often are just a workaround for a missing select(2). On linux, for instance, select and related functions are really strong. You can select in one and the same call a serial port, a TCP socket and a file if you want. In recently it seems Java people started to understand and did some new (not that new, java5 IIRC :)) APIs allowing things like that. They also introduced a new `ByteBuffer' for JNI performance IIRC. Applications using this also are not compatible to javax.comm. Also, the abstraction isn't sufficient IMHO, because applications cannot use InputStream because of missing timeouts, so they must use e.g. SerialPort and now all abstraction is gone, because timeouts for a SerialPort and SocketChannel are completely different in Java (unlike select(), which does abstract). So I think the `break' from javax.comm should be no issue. - rxtx is not required to provide high performance (I think). Of course it should be fast and stable, but IMHO no high performance is needed; typical applications probably just have to work with a few serial ports. When high performance is an issue, I think it would be required that on the JNI interface multiple ports can be processed with a single thread and a single call, for instance if data is buffered per port and the single call processes all active ports or so. In such a case I think it would be likely that a kind of BSD socket API interface would result as internal JNI interface, but this also is another topic. I think 64 port serial console servers are rare today and probably not implemented in Java :-) oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Steffen.DETTMER at ingenico.com Fri Apr 17 04:24:16 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 17 Apr 2009 12:24:16 +0200 Subject: [Rxtx] Problems with read timeout In-Reply-To: <49E80EEF.6000503@bbs.darktech.org> References: <49E64A4A.1050806@bbs.darktech.org> <49E80EEF.6000503@bbs.darktech.org> Message-ID: <20090417102416.GM13774@elberon.bln.de.ingenico.com> Hi, * cowwoc wrote on Fri, Apr 17, 2009 at 01:09 -0400: > I want step 4 to block until COM1 receives the full message before it Do you really want to block? Block means infinite timeout. In case of a serial communication issue (or such) your application will just hang. I think, usually, timeouts are no errors. On timeouts, often it is not correct to close the communication mean where it occured. > attempts the read operation but I'm not sure how to achieve > this. I was somewhat expecting the write() or flush() operation > to block until the send was complete... Any ideas? Typically you cannot know when the send really happend. OS buffers probably many bytes and UART several bits at least. With hardware flow control it might happen that sending a byte takes long time (seconds, minutes or even more). For testing your new implementation maybe you use some other tool (application or hardware, like a modem) to avoid that e.g. receive issues on one side are looking like send issues on the other - or so. Maybe you start some timer for a total timeout and call read in a loop (with the remaining time of the timer as timeout, half of the remaining time limited to a big fixed value or a small fixed value to poll)? When using small timeouts (lets say below 100 ms, not sure if 300 ms could be a problem too), be aware that because of interupt delays, other processes consuming CPU time or whatever reasons an operation can take longer, so a timer is expired but no timeout happend. Sometimes even (debug) log file writing can take so much or even more time. So for a more robust implementation it could help to invoke a read with a very short timeout right after the timer expired. If there is some (internally OS buffered) data it will be returned (this should not considered a timeout, i.e. not throw an exception). oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Kustaa.Nyholm at planmeca.com Fri Apr 17 05:54:50 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 17 Apr 2009 14:54:50 +0300 Subject: [Rxtx] Java5 support In-Reply-To: <9146C76F-17D8-468D-A0F2-CAC9512BCDD6@cometway.com> Message-ID: > From: Paul Cunningham > [snip] in a world where RS-232 is only used for legacy support of devices > with no hope for firmware updates. This is not entirely true. I mean there is a lot more to RS-232 than 'legacy support of devices with no hope for firmware updates'. The alternatives to RS-232 (USB comes to mind) are not that attractive to many niche device / system manufactures because implementing them and supporting them, especially across many platforms is often beyond their means and capabilities. Hence even new designs are based on RS232 on way or the other. RS232 is about the only easy(ish) way to access the outside world from in a relatively device and platform independent manor. Also even when implementing USB is feasible the other limitation of USB may make RS232 much more attractive proposition. Five meter cable length limitation and the utter unpracticality of implementing galvanic isolation come to mind. br Kusti BTW I did not quite get what the rest of the sentence ('with no hope for firmware updates') referred to. From Kustaa.Nyholm at planmeca.com Fri Apr 17 05:56:05 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 17 Apr 2009 14:56:05 +0300 Subject: [Rxtx] FW: Java5 support In-Reply-To: Message-ID: Ooops, sorry Gili, this was meant for the list. > From: Kustaa Nyholm > Date: Fri, 17 Apr 2009 14:41:48 +0300 > To: cowwoc > Conversation: [Rxtx] Java5 support > Subject: Re: [Rxtx] Java5 support > > > Nor Mac support and I think the Linux support is not complete either. > > It is a pity. I'm afraid it reflects the state of desktop Java which is sad > because there really are no alternative to Java for writing rich desktop > applications that look reasonably native on each of the three major platforms > in mostly platform agnostic way. > > br Kusti > >> From: cowwoc >> >> Last time I looked this, there was no usable Windows version. >> >> Gili >> >> Trent Jarvi wrote: >>> Hi Paul, >>> >>> JSR 80 is USB HID support. >>> >>> http://javax-usb.org/ >>> http://jcp.org/aboutJava/communityprocess/final/jsr080/index.html >>> >>> On Thu, 16 Apr 2009, Paul Cunningham wrote: >>> >>>> btw, i mean no disrespect to anyone actively developing an RS-232 >>>> interfaces for new devices. >>>> >>>> in fact my most recent project involved a freescale chip using a UART- >>>> to-USB chip, as i have no idea how to go about interfacing USB devices >>>> to Java. RXTX behaved very well, even when the USB driver didn't. >>>> >>>> is there anything resembling javax.comm for USB? -pc >>>> >>>> >>>> On Apr 16, 2009, at 5:52 PM, Paul Cunningham wrote: >>>> >>>>> in a world where RS-232 is >>>>> only used for legacy support of devices with no hope for firmware >>>>> updates. >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx ------ End of Forwarded Message From Kustaa.Nyholm at planmeca.com Fri Apr 17 05:56:42 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 17 Apr 2009 14:56:42 +0300 Subject: [Rxtx] FW: Java5 support In-Reply-To: Message-ID: Oops again, this was meant for the list. Sorry. ------ Forwarded Message > From: Kustaa Nyholm > Date: Fri, 17 Apr 2009 14:38:36 +0300 > To: Steffen DETTMER > Conversation: [Rxtx] Java5 support > Subject: Re: [Rxtx] Java5 support > >> From: Steffen DETTMER > >> - IMHO Javadoc of javax.comm is /not/ good....[SNIP] > Maybe documentation in javax.comm isnot first class but it is better than no > documentation. > > Having said that I have no desire to get this documentation copied over to > gnu.io I can just as well use the little bits I need from the javadocs of > javax.comm. > > After all this is a very small API and I would very much like it to stay that > way.e in some Makefile. >> >> - Some `wrapper' adding usability to the Java APIs (like >> InputStream) IMHO is essential and required anyway. >> > Me for one definitely don't need anywrapper, I'm happy with the way > the API is. javax.comm/gnu.io is a very low level abstraction of > the under laying hardware, and IMO it should stay that way. Anyone > interested in a better wrapper is of course free to implement and > publish one, if so inclined. But let's keep this in perspective, > serial port is small, but sometimes crucial, well established thing > that will not get better by braking things by improving it. > >> I dislike the APIs, for instance InputStream and those. It is >> almost impossible to write really correct code with it. It is >> sufficient for simple GUI stuff you can kill if it blocks or >> so, but for e.g. server applications IMHO it is not sufficient. >> Timeouts are needed and so on. > Would be fascinating to learn more about this as I've never had > any problem with APIs. > >> >> Well, this would just lead to a API discussion which would be a >> different topic. >> >> Because a wrapper is needed, package namings IMHO are no issue. >> Personally, I would prefer for some future version to drop the >> logical dependency to the stange javax.comm.SerialPort thingy, >> instead have a clean simple but specific JNI interface. >> This is `an implementation detail', so rxtx can do whatever is >> appropriate :) >> > I would suspect that most user would not welcome anything that brakes > compatibility with the existing API. Let's improve something in > a separate wrapper project. >> >> >> - this java event and multi-threading mixes IMHO often are just a >> workaround for a missing select(2). On linux, for instance, >> select and related functions are really strong. You can select >> in one and the same call a serial port, a TCP socket and a file >> if you want. In recently it seems Java people started to >> understand and did some new (not that new, java5 IIRC :)) APIs >> allowing things like that. They also introduced a new >> `ByteBuffer' for JNI performance IIRC. >> >> Applications using this also are not compatible to javax.comm. >> Also, the abstraction isn't sufficient IMHO, because >> applications cannot use InputStream because of missing >> timeouts, so they must use e.g. SerialPort and now all >> abstraction is gone, because timeouts for a SerialPort and >> SocketChannel are completely different in Java (unlike >> select(), which does abstract). > I'm not sure I followed/understood everything above but it smelt > like *one* POV and I suspect, that if I had understood what I read, that > I would have had a different POV. >> >> So I think the `break' from javax.comm should be no issue. > Depending on what above means this could be huge issues for many of us. > But I think I've said that several times already. >> >> >> >> - rxtx is not required to provide high performance (I think). > Agree. >> >> Of course it should be fast and stable, but IMHO no high >> performance is needed; typical applications probably just have >> to work with a few serial ports. > Agree. >> >> When high performance is an issue, I think it would be required >> that on the JNI interface multiple ports can be processed with >> a single thread and a single call, for instance if data is >> buffered per port and the single call processes all active >> ports or so. In such a case I think it would be likely that a >> kind of BSD socket API interface would result as internal JNI >> interface, but this also is another topic. > This paragraph had so many assumptions that I refrain from commenting > other than that it portrays one POV which again I suspect I do not > care for. >> >> I think 64 port serial console servers are rare today and >> probably not implemented in Java :-) >> >> >> oki, >> >> Steffen >> > br Kusti ------ End of Forwarded Message From Kustaa.Nyholm at planmeca.com Fri Apr 17 06:01:15 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 17 Apr 2009 15:01:15 +0300 Subject: [Rxtx] rxtx list configuration... Message-ID: Trent, Would it be possible to configure the mail headers for mail that comes from the list so that the 'from' field would be 'rxtx at qbang.org' and not the posters email address? That would save me a couple of clicks each time I reply (now I need to 'reply to all' and delete the other recipients) and a few mistakes (when I hit the 'reply to sender'). Just did that mistake twice in a row, my apologies for those concerned. Just a wish. br Kusti From ilkka at myller.com Fri Apr 17 06:17:14 2009 From: ilkka at myller.com (Ilkka Myller) Date: Fri, 17 Apr 2009 15:17:14 +0300 Subject: [Rxtx] Java5 support In-Reply-To: References: Message-ID: <934E311F-9FCC-4EF2-A1D5-960285363221@myller.com> I completely agree with Kustaa on this one. Our company is developing devices with embedded hardware. We are using RS-232 (and other serial interfaces) with both old and new designs. Serial interfaces are convenient/practical with embedded low cost microprocessors etc. where hardware/software overhead and complexity of more "modern" interfaces is just .. well.. overhead. So, in my opinion, RS-232 (and others) are not obsolete or legacy - at least in industrial/embedded development. It is true, that there are little or no new consumer devices with RS-232 interfaces. -- I >> From: Paul Cunningham >> [snip] in a world where RS-232 is only used for legacy support of >> devices >> with no hope for firmware updates. > > This is not entirely true. I mean there is a lot more to RS-232 than > 'legacy > support of devices with no hope for firmware updates'. > > The alternatives to RS-232 (USB comes to mind) are not that > attractive to > many niche device / system manufactures because implementing them and > supporting them, especially across many platforms is often beyond > their > means and capabilities. Hence even new designs are based on RS232 on > way > or the other. > > RS232 is about the only easy(ish) way to access the outside world > from in a > relatively device and platform independent manor. > > Also even when implementing USB is feasible the other limitation of > USB may > make RS232 much more attractive proposition. Five meter cable length > limitation and the utter unpracticality of implementing galvanic > isolation > come to mind. > > br Kusti > > BTW I did not quite get what the rest of the sentence ('with no hope > for > firmware updates') referred to. > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From cowwoc at bbs.darktech.org Fri Apr 17 06:48:31 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Fri, 17 Apr 2009 08:48:31 -0400 Subject: [Rxtx] Problems with read timeout In-Reply-To: <49E80EEF.6000503@bbs.darktech.org> References: <49E64A4A.1050806@bbs.darktech.org> <49E80EEF.6000503@bbs.darktech.org> Message-ID: <49E87A9F.9070200@bbs.darktech.org> To be clear, I'm not really sure I want write() to block. I just want a way to get a timeout if no data has been read or written in at least X ms (i.e. we're waiting on the remote end) *and* we're blocked on a read() or write() command. It's not clear to me how to achieve this, with or without the new NIO APIs. I'm fairly certain the only way this will work is if flush() blocks until the remote end receives the full message. I'll look into the C code later on tonight to see if this is possible. What are your thoughts on this? Gili cowwoc wrote: > > I've been playing with the read timeout behavior and I'm seeing some > non-intuitive behavior. > > I've got an endless loop that does the following: > > 1) COM1 and COM2 are connected to one another. They are opened at 300 > baud, with read timeout of 300ms. > 2) COM1 writes "CONNECTION" > 3) COM2 reads "CONNECTION" > 4) COM2 writes "CONNECTION 9600 8 NONE 1 RTS/CTS" and tries a read > operation. > 5) COM1 receives "CONNECTION 960" when suddenly COM2 hits the 300ms read > timeout. COM2 gets an IOException (caused by the timeout), and closes > the serial port. > 6) COM1 never gets the full message because the connection was closed in > middle of sending. > > I want step 4 to block until COM1 receives the full message before > it attempts the read operation but I'm not sure how to achieve this. I > was somewhat expecting the write() or flush() operation to block until > the send was complete... Any ideas? > > Gili > From paul at cometway.com Fri Apr 17 08:23:18 2009 From: paul at cometway.com (Paul Cunningham) Date: Fri, 17 Apr 2009 10:23:18 -0400 Subject: [Rxtx] Java5 support In-Reply-To: References: Message-ID: <91A48B92-4A0D-4030-9129-F0657723765B@cometway.com> >> From: Paul Cunningham >> [snip] in a world where RS-232 is only used for legacy support of >> devices >> with no hope for firmware updates. > > This is not entirely true. I mean there is a lot more to RS-232 than > 'legacy > support of devices with no hope for firmware updates'. Hi Kustaa -- Oh I agree with you, mostly. Read my other post. Its just that the money isn't really there to commercially push RS-232 as a mainstream solution anymore. It's difficult these days to find a computer with a DB9 port for doing RS-232 stuff. Anyone still making that kind of hardware is seriously industrial or fringe/hobbyist. On Apr 17, 2009, at 7:54 AM, Kustaa Nyholm wrote: > BTW I did not quite get what the rest of the sentence ('with no hope > for > firmware updates') referred to. Hobbyists are always interested in finding new uses for uniquely functional serial devices that are no longer made, supported, and/or documented. While reverse engineering can be fun, sometimes bad serial driver code and protocol anomalies make it less than straight-forward to implement a reliable interface, and it's not because RXTX isn't working correctly. I have a cool little device that we use to monitor the temperature of our server room using RXTX, but the code I had to write to get it working was less than conventional. -pc -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090417/61103c37/attachment-0002.html From tjarvi at qbang.org Fri Apr 17 08:34:13 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 17 Apr 2009 08:34:13 -0600 (MDT) Subject: [Rxtx] Problems with read timeout In-Reply-To: <49E87A9F.9070200@bbs.darktech.org> References: <49E64A4A.1050806@bbs.darktech.org> <49E80EEF.6000503@bbs.darktech.org> <49E87A9F.9070200@bbs.darktech.org> Message-ID: The bytesavailable event can be used to start your read. There is also an outputbufferempty event. On Fri, 17 Apr 2009, cowwoc wrote: > > To be clear, I'm not really sure I want write() to block. I just want a > way to get a timeout if no data has been read or written in at least X > ms (i.e. we're waiting on the remote end) *and* we're blocked on a > read() or write() command. > > It's not clear to me how to achieve this, with or without the new NIO > APIs. I'm fairly certain the only way this will work is if flush() > blocks until the remote end receives the full message. I'll look into > the C code later on tonight to see if this is possible. What are your > thoughts on this? > > Gili > > cowwoc wrote: >> >> I've been playing with the read timeout behavior and I'm seeing some >> non-intuitive behavior. >> >> I've got an endless loop that does the following: >> >> 1) COM1 and COM2 are connected to one another. They are opened at 300 >> baud, with read timeout of 300ms. >> 2) COM1 writes "CONNECTION" >> 3) COM2 reads "CONNECTION" >> 4) COM2 writes "CONNECTION 9600 8 NONE 1 RTS/CTS" and tries a read >> operation. >> 5) COM1 receives "CONNECTION 960" when suddenly COM2 hits the 300ms read >> timeout. COM2 gets an IOException (caused by the timeout), and closes >> the serial port. >> 6) COM1 never gets the full message because the connection was closed in >> middle of sending. >> >> I want step 4 to block until COM1 receives the full message before >> it attempts the read operation but I'm not sure how to achieve this. I >> was somewhat expecting the write() or flush() operation to block until >> the send was complete... Any ideas? >> >> Gili >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Steffen.DETTMER at ingenico.com Fri Apr 17 09:17:51 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 17 Apr 2009 17:17:51 +0200 Subject: [Rxtx] FW: Java5 support In-Reply-To: References: Message-ID: <20090417151751.GD16563@elberon.bln.de.ingenico.com> * Kustaa Nyholm wrote on Fri, Apr 17, 2009 at 14:56 +0300: > > - Some `wrapper' adding usability to the Java APIs (like > > InputStream) IMHO is essential and required anyway. > > > Me for one definitely don't need anywrapper, I'm happy with the way > the API is. javax.comm/gnu.io is a very low level abstraction of > the under laying hardware, and IMO it should stay that way. Well, so it seems it is a matter of opinion (for me, it is neither an abstraction nor low level; actually, InputStream IMHO is a high [too high] level). (I also think it should stay the way as it is, which IMHO is gnu.io not javax.comm) > Anyone interested in a better wrapper is of course free to > implement and publish one, if so inclined. But let's keep this > in perspective, serial port is small, but sometimes crucial, > well established thing that will not get better by braking > things by improving it. Is the SerialPort API a `well established thing'? I would consider it exotic - most people / applications never used it, I guess. > > I dislike the APIs, for instance InputStream and those. It is > > almost impossible to write really correct code with it. It is > > sufficient for simple GUI stuff you can kill if it blocks or > > so, but for e.g. server applications IMHO it is not sufficient. > > Timeouts are needed and so on. > > Would be fascinating to learn more about this as I've never had > any problem with APIs. Does this mean you are using InputStream for communication and you never had any problem with it? Including no timeout related problems appeared? We had and have a lot here. Sometimes timeouts are not precise enough and synchronisation with embedded stuff fails. Issues with serial w/o (hardware/any) flow control and performance. Issues with lower performance because of unprecise polling timeouts. To big timeouts leading to slow systems and to small timeouts to leading to trouble to unwanted repeations or messages where message boundaries depend on timeouts (like X.25 Gateways without ADPU protocols). I think the most troublesome things here are those transparent protocol converters / gateways and the protocols that depend on timeouts (like `100 ms silence for block separation' or `optional CRC within X.25 frame timeout or set more bit' converted to serial line). If you're using some PPP with TCP on top, I guess this wouldn't be critical because TCP cares about timeouts and retransmissions, but on serial links we often have to implement various protocols without such features. I think, with just an InputStream / OutputStream API it would be almost impossible to write a good, stable and performant TCP/IP/PPP stack. > > Well, this would just lead to a API discussion which would be a > > different topic. > > > > Because a wrapper is needed, package namings IMHO are no issue. > > Personally, I would prefer for some future version to drop the > > logical dependency to the stange javax.comm.SerialPort thingy, > > instead have a clean simple but specific JNI interface. > > This is `an implementation detail', so rxtx can do whatever is > > appropriate :) > > > I would suspect that most user would not welcome anything that > brakes compatibility with the existing API. I would not be surprised if more use gnu.io than javax.comm, so also because of this it would be gnu.io that rxtx should be compatible to! (actually this is a guess, maybe someone has some statistics or makes some poll? I vote for gnu.io and would be able to find more inside the company :)) The JNI interface isn't to be used by the applications; they should work on gnu.io.SerialPort and related objects but never directly on all the JNI functions. >> timeouts, so they must use e.g. SerialPort and now all >> abstraction is gone, because timeouts for a SerialPort and >> SocketChannel are completely different in Java (unlike >> select(), which does abstract). >> > I'm not sure I followed/understood everything above but it > smelt like *one* POV and I suspect, that if I had understood > what I read, that I would have had a different POV. yeah, maybe... (but maybe BSD socket API style is just strong and InputStream API style is just weak - and that recent Java APIs come closer to BSD socket API style IMHO could be an indication that others agree). >> So I think the `break' from javax.comm should be no issue. > Depending on what above means this could be huge issues for > many of us. But I think I've said that several times already. well, I thought almost noone is still using javax.comm, thought only gnu.io was maintained and bugfixed since quite some time (years) - even if technically it is implemented in a branch 0.1.0. This branch IMHO is also an implementation detail; I think (not sure, of course I can be wrong, let's ask Trent and the team). I think rxtx users should not care from which branch a release is built. > > When high performance is an issue, I think it would be required > > that on the JNI interface multiple ports can be processed with > > a single thread and a single call, for instance if data is > > buffered per port and the single call processes all active > > ports or so. In such a case I think it would be likely that a > > kind of BSD socket API interface would result as internal JNI > > interface, but this also is another topic. > > > This paragraph had so many assumptions that I refrain from > commenting other than that it portrays one POV which again I > suspect I do not care for. An alternative, which could be more helpful than refraining from commenting :-), could be to add other high performance setups that could exist on PCs (or where rxtx is running one). anyway, we agree that no ultra high performance requirements exist (probably). I admit that I accidently focussed on UART style hardware for 115kbaud or so, where one port is easy to handle. Yes, of course you are right, there could be a high performance requirement even for setups with few ports, even with a single one. Do you have an example of it which is not very specific (and thus wants to use rxtx)? IMHO it does not help much to talk about specific special serial power hardware which may even require to be accessed with specific driver APIs, because this is out of scope of rxtx :-) oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Steffen.DETTMER at ingenico.com Fri Apr 17 09:40:07 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 17 Apr 2009 17:40:07 +0200 Subject: [Rxtx] Java5 support In-Reply-To: <91A48B92-4A0D-4030-9129-F0657723765B@cometway.com> References: <91A48B92-4A0D-4030-9129-F0657723765B@cometway.com> Message-ID: <20090417154006.GE16563@elberon.bln.de.ingenico.com> * Paul Cunningham wrote on Fri, Apr 17, 2009 at 10:23 -0400: > > This is not entirely true. I mean there is a lot more to > > RS-232 than 'legacy support of devices with no hope for > > firmware updates'. > > Hi Kustaa -- Oh I agree with you, mostly. Read my other post. > Its just that the money isn't really there to commercially > push RS-232 as a mainstream solution anymore. this depends where you look. On a rxtx mailing list, RS-232 surely is mainstream - guess everyone here is using it :-) Network routers usually still have a serial console and embedded board often have one (which probably counts as industrial). > It's difficult these days to find a computer with a DB9 port > for doing RS-232 stuff. Anyone still making that kind of > hardware is seriously industrial or fringe/hobbyist. Yes, consumer devices are rarely with RS232 now, but have USB (or bluetooth). But on PC, you usually can plug some PCMCIA / PCI card or a USB interface to connect, which sometimes also have their issues... Maybe would be interesting to see what people are using rxtx and RS232 here for? The temperature monitor is nice :) I could imagine a few other similar things people use here (connecting to some small controller/sensor board or so). We use it to communicate with various embedded devices, cash registers, small serial printers and communication means like modems and pads (mostly in C but some in Java). oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Steffen.DETTMER at ingenico.com Fri Apr 17 09:51:56 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 17 Apr 2009 17:51:56 +0200 Subject: [Rxtx] rxtx list configuration... In-Reply-To: References: Message-ID: <20090417155156.GF16563@elberon.bln.de.ingenico.com> [OT] * Kustaa Nyholm wrote on Fri, Apr 17, 2009 at 15:01 +0300: > Would it be possible to configure the mail headers for mail > that comes from the list so that the 'from' field would be > 'rxtx at qbang.org' and not the posters email address? Please don't rewrite the `From:' field, because then it would not visible who wrote a posting and it would violate standards potentionally leading to all sort of problems. > That would save me a couple of clicks each time I reply (now I > need to 'reply to all' and delete the other recipients) and a > few mistakes (when I hit the 'reply to sender'). There are mail programs (MUAs) and Plug-Ins for others that handle this automatically. > Just did that mistake twice in a row, my apologies for those concerned. no problem (other way around would be bad :)). oki, Steffen BTW: http://www.unicom.com/pw/reply-to-harmful.html http://woozle.org/~neale/papers/reply-to-still-harmful.html> About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Steffen.DETTMER at ingenico.com Fri Apr 17 09:54:50 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 17 Apr 2009 17:54:50 +0200 Subject: [Rxtx] Java5 support In-Reply-To: <20090417154006.GE16563@elberon.bln.de.ingenico.com> References: <91A48B92-4A0D-4030-9129-F0657723765B@cometway.com> <20090417154006.GE16563@elberon.bln.de.ingenico.com> Message-ID: <20090417155450.GG16563@elberon.bln.de.ingenico.com> * Steffen Dettmer wrote on Fri, Apr 17, 2009 at 17:40 +0200: > Maybe would be interesting to see what people are using rxtx and > RS232 here for? http://rxtx.qbang.org/wiki/index.php/Projects is impressing. oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From bschlining at gmail.com Fri Apr 17 10:25:52 2009 From: bschlining at gmail.com (Brian Schlining) Date: Fri, 17 Apr 2009 09:25:52 -0700 Subject: [Rxtx] Java5 support In-Reply-To: <20090417154006.GE16563@elberon.bln.de.ingenico.com> References: <91A48B92-4A0D-4030-9129-F0657723765B@cometway.com> <20090417154006.GE16563@elberon.bln.de.ingenico.com> Message-ID: > > Maybe would be interesting to see what people are using rxtx and > RS232 here for? The vast majority of oceanographic instruments that we work with have serial connectors. These include acoustic doppler current profilers (ADCP), conductivity-temperature-depth sensors (CTD), radiometers, oxygen sensors, and meteorology sensors. We also use pro-grade VCR's that have serial ports on them for control. We use RXTX on a range of JVM's from J9 through the latest Sun JVM. A particularly cool project that we use RXTX for is SIAM ( http://www.mbari.org/moos/siam/siam.htm). Especially note the PUCK protocol (http://www.mbari.org/pw/puck.htm). Essentially, we create instruments with a little blob of Java code embedded with it as the instrument driver. When the instrument gets plugged in the host controller grabs the driver off and starts running it. Voila, plug-and-work instruments (almost always controlled via a serial port using RXTX) -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090417/f92c3bf8/attachment-0002.html From cowwoc at bbs.darktech.org Fri Apr 17 10:50:15 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Fri, 17 Apr 2009 12:50:15 -0400 Subject: [Rxtx] Java5 support In-Reply-To: <20090417095501.GL13774@elberon.bln.de.ingenico.com> References: <91BF244D-07E4-4B30-9F9D-0DC0964045B4@cometway.com> <49E7900D.3060100@bbs.darktech.org> <20090417095501.GL13774@elberon.bln.de.ingenico.com> Message-ID: <49E8B347.9010609@bbs.darktech.org> I wanted to address two points that have been brought up: > New development doesn't use RS-232. Actually, I've seen quite a few devices using RS-232 over USB. > InputStream isn't appropriate for RS-232 because of timeouts. This is addressed by java.nio.Channels. Gili From greg.johnson at rbr-global.com Fri Apr 17 10:51:44 2009 From: greg.johnson at rbr-global.com (Greg Johnson) Date: Fri, 17 Apr 2009 12:51:44 -0400 Subject: [Rxtx] Java5 support In-Reply-To: References: <91A48B92-4A0D-4030-9129-F0657723765B@cometway.com> <20090417154006.GE16563@elberon.bln.de.ingenico.com> Message-ID: <42447237-7898-470E-835B-A09A6119458F@rbr-global.com> And we make some of those oceanographic instruments - and we use RXTX to configure and download data from them... We run our code on win32/ osx/linux (x86) and the Aonix Perc Ultra JVM (arm). (Brian, please say hi to Tom O'R. for me - I didn't realise mbari was represented on this list :) Cheers, greg -- Greg Johnson, PhD Director of Engineering http://www.rbr-global.com greg.johnson at rbr-global.com +1.613.233.1621 (GMT-5) office +1.613.986.1621 (GMT-5) mobile See us at: Oceans '09 IEEE, Bremen, Germany, May 11 - 14, 2009 On 17-Apr-09, at 12:25 , Brian Schlining wrote: > Maybe would be interesting to see what people are using rxtx and > RS232 here for? > > The vast majority of oceanographic instruments that we work with > have serial connectors. These include acoustic doppler current > profilers (ADCP), conductivity-temperature-depth sensors (CTD), > radiometers, oxygen sensors, and meteorology sensors. We also use > pro-grade VCR's that have serial ports on them for control. We use > RXTX on a range of JVM's from J9 through the latest Sun JVM. > > A particularly cool project that we use RXTX for is SIAM (http://www.mbari.org/moos/siam/siam.htm > ). Especially note the PUCK protocol (http://www.mbari.org/pw/ > puck.htm). Essentially, we create instruments with a little blob of > Java code embedded with it as the instrument driver. When the > instrument gets plugged in the host controller grabs the driver off > and starts running it. Voila, plug-and-work instruments (almost > always controlled via a serial port using RXTX) > > -- > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > Brian Schlining > bschlining at gmail.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090417/d2048c45/attachment-0002.html From tjarvi at qbang.org Fri Apr 17 11:16:45 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 17 Apr 2009 11:16:45 -0600 (MDT) Subject: [Rxtx] Java5 support In-Reply-To: <42447237-7898-470E-835B-A09A6119458F@rbr-global.com> References: <91A48B92-4A0D-4030-9129-F0657723765B@cometway.com> <20090417154006.GE16563@elberon.bln.de.ingenico.com> <42447237-7898-470E-835B-A09A6119458F@rbr-global.com> Message-ID: Disclosure on my part. rxtx is used in the base MATLAB product with an estimated 4 million usrs. http://www.informaworld.com/smpp/title~content=t795248263~db=all http://www.mathworks.com/products/instrument/supportedio13781.html We see some funky projects :) USB serial dongle drivers improving over the last few years has actually boosted the popluarity of serial use. On Fri, 17 Apr 2009, Greg Johnson wrote: > And we make some of those oceanographic instruments - and we use RXTX to > configure and download data from them... ?We run our code on win32/osx/linux > (x86) and the Aonix Perc Ultra JVM (arm). > (Brian, please say hi to Tom O'R. for me - I didn't realise mbari was > represented on this list :) > > Cheers, > > greg > > -- > Greg Johnson, PhD > Director of Engineering > http://www.rbr-global.com > greg.johnson at rbr-global.com > +1.613.233.1621 (GMT-5) office > +1.613.986.1621 (GMT-5) mobile > > See us at: Oceans '09 IEEE, Bremen, Germany, ?May 11 - 14, 2009 > > > On 17-Apr-09, at 12:25 , Brian Schlining wrote: > > Maybe would be interesting to see what people are > using rxtx and > RS232 here for? > > > The vast majority of?oceanographic?instruments that we work with have > serial connectors. These include acoustic doppler current profilers > (ADCP), conductivity-temperature-depth sensors (CTD), radiometers, > oxygen sensors, and?meteorology?sensors. We also use pro-grade VCR's > that have serial ports on them for control. We use RXTX on a range of > JVM's from J9 through the latest Sun JVM. > > A particularly cool project that we use RXTX for is SIAM > (http://www.mbari.org/moos/siam/siam.htm). Especially note the PUCK > protocol (http://www.mbari.org/pw/puck.htm).?Essentially, we create > instruments with a little blob of Java code embedded with it as the > instrument driver. When the instrument gets plugged in the host > controller grabs the driver off and starts running it. Voila, > plug-and-work instruments (almost always controlled via a serial port > using RXTX) > > -- > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > Brian Schlining > bschlining at gmail.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > From Bob_Jacobsen at lbl.gov Fri Apr 17 18:19:16 2009 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Fri, 17 Apr 2009 17:19:16 -0700 Subject: [Rxtx] Java5 support In-Reply-To: <20090417155450.GG16563@elberon.bln.de.ingenico.com> References: <91A48B92-4A0D-4030-9129-F0657723765B@cometway.com> <20090417154006.GE16563@elberon.bln.de.ingenico.com> <20090417155450.GG16563@elberon.bln.de.ingenico.com> Message-ID: RXTX is not just RS232. A _lot_ of USB equipment provide a serial-port-like interface, e.g. via virtual com port drivers. For a device manufacturer, dropping an FTDI or SiLabs chip into their device to provide a computer interface solves a lot of problems. The chips come with drivers for N varients of Windows, Linux, Mac, etc, so the device manufacturer doesn't have to deal with the computer access issues at all. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From scldad at sdc.com.au Fri Apr 17 19:22:04 2009 From: scldad at sdc.com.au (Stephen Davies) Date: Sat, 18 Apr 2009 10:52:04 +0930 Subject: [Rxtx] Java5 support In-Reply-To: <20090417154006.GE16563@elberon.bln.de.ingenico.com> References: <91A48B92-4A0D-4030-9129-F0657723765B@cometway.com> <20090417154006.GE16563@elberon.bln.de.ingenico.com> Message-ID: <200904181052.04460.scldad@sdc.com.au> We use rxtx to interface to a wide variety of remote sensors located in paddocks around the country. The sensors and controlling loggers are manufactured by Campbell Scientific and the loggers have "real" RS232 interfaces. Cheers, Stephen On Saturday 18 April 2009 01:10:07 Steffen DETTMER wrote: > Maybe would be interesting to see what people are using rxtx and > RS232 here for? -- ============================================================================= Stephen Davies Consulting P/L Voice: 08-8177 1595 Adelaide, South Australia. Fax : 08-8177 0133 Computing & Network solutions. Mobile:040 304 0583 VoIP:sip:1132210 at sip1.bbpglobal.com From johnco3 at gmail.com Sat Apr 18 14:39:01 2009 From: johnco3 at gmail.com (John Coffey) Date: Sat, 18 Apr 2009 16:39:01 -0400 Subject: [Rxtx] Serial Port Hangs with 8K buffers - fix included Message-ID: Trent, it would be great if you could forward this suggestion/fix to the users group. There is API in the javax.comm (or gnu.io) as far as I am aware to set the 'wierd science' parameters that fall outside the rather narrow scope laid out in the framework by sun. The most natural fit would appear to be in the setSerialPortParams. Perhaps if some negative value for the baud rate were specified the interpretaton could be opened up for other things. The only restriction is that the serial port cannot be open at the time this is called (this is not a change) John - Hide quoted text - On Thu, Apr 16, 2009 at 2:17 AM, Trent Jarvi wrote: Hi John, Would you mind if I forward this to the rxtx maillist for review? This falls under the 'weird science' group of things rxtx likes to do but isn't exactly in the API. Also, could go into a little more detail in the following? You don't want to break the API but you need to set that bit? "however I know we cannot violate suns interface definitions there" On Thu, 16 Apr 2009, John Coffey wrote: Trent, I see that RXTX 2.2 is nearing completion. I was happy to see that the non standard baud multiplier fixes made it into the latest qbang as I was previously maintaining a patched 2.1.7 version for my application. I needed to make the following fix to your termios.c native C wrapper in RxTx (both 2.1.7 and more recently 2.2 - pre1) as I don't know a way of specifying the input and output queue sizes after the comm port has been configured and opened by java. My application is a bidirectional application that works file when the block sizes are 2K however, the next step in my protocol is a jump to 8K (actually 8200 bytes) and the data gets stuck approx 2k into the transfer - anyway to fix this I made the default buffer sizes 8200 as you can see below. Can you perhaps think of some way of doing this better as I have 8 serial ports opened and they don't all require 16k's worth of serial io buffering. Perhaps the best way is via the SerialPort.setSerialPortParams native interface to the DLL however I know we cannot violate suns interface definitions there. With the hard coded change to the existing hack bwlow, I have it working very reliably now - although on windows x64, I still have the problem since I dont have a 64 bit compiler for windows. Hope this is useful if( !SetupComm( port->hComm, 2048, 1024 ) ) // @JC allocate an 8K RX and TX buffers associated with the // serial channel, this is for large block support to fix // a hangup in the virtual serial port driver for XP if( !SetupComm( port->hComm, 8200, 8200) ) { YACK(); return -1; } John Coffey -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090418/7784195b/attachment.html From cowwoc at bbs.darktech.org Wed Apr 1 22:05:13 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Thu, 02 Apr 2009 00:05:13 -0400 Subject: [Rxtx] Windows 64-bit support? Message-ID: <49D43979.4050702@bbs.darktech.org> Hi, I'd like to run RXTX under the Windows 64-bit JVM. Are there plans to release an official 64-bit version anytime soon? Gili From bill7007 at gmail.com Thu Apr 2 16:01:17 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Thu, 2 Apr 2009 18:01:17 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel Message-ID: Hi, I have an rxtx serial application that used to work reliably until I had to move it to newer hardware and kernel. Now, the application sometimes hangs near first port use. When it does hang, it can be released by starting a second copy of the application which is locked out of the ports but does release the first process. Upgraded from rxtx-2.1-7-r2 to rxtx-2.2pre2 but still hangs. Tried to rebuild on the target machine and ran into the 'UTS_RELEASE' undeclared problem so holding on that approach. Recompiled OK on a 2.6.9-42.0.3.ELsmp system. Debug messages were turned on using: "./configure --enable-DEBUG" and modified RXTXPort.java with: "debug = true;" "z = new Zystem(Zystem.PRINT_MODE);" Below is capture of the application with debugging enabled. It show the application hang point, and the second application's printout at the release point. (pre3 is the locally modified version of pre2) Any suggestions on how to pin this down further? Thanks, +BillJ $ java -version java version "1.5.0_06" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05) Java HotSpot(TM) Client VM (build 1.5.0_06-b05, mixed mode, sharing) $ uname -a Linux qms4 2.6.18-92.1.6.el5 #1 SMP Wed Jun 25 13:49:24 EDT 2008 i686 i686 i386 GNU/Linux ***CAPTURE: [qms at qms4 ~]$ ./qms/ScriptFiles/startup.sh Thu Apr 02 13:35:45 EDT 2009:Setting Log File to:/home/qms/qms/QMS.log Thu Apr 02 13:35:45 EDT 2009:TSettings.HandleIni:ReUsing Ini file:/home/qms/qms/qms.properties WARNING: RXTX Version mismatch Jar version = RXTX-2.2pre2 native lib Version = RXTX-2.2pre3 fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB2 fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB1 fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB0 fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile RXTXPort {} RXTX WARNING: This library was compiled to run with OS release 2.4.20 and you are currently running OS release 2.6.18-92.1.6.el5. In some cases this can be a problem. Try recompiling RXTX if you notice strange behavior. If you just compiled RXTX make sure /usr/include/linux is a symbolic link to the include files that came with the kernel source and not an older copy. press enter to continue RXTXPort:RXTXPort(/dev/ttyUSB2) called fhs_lock: creating lockfile: 10127 open: locking worked for /dev/ttyUSB2 open: fd returned is 8 RXTXPort:MontitorThread:MonitorThread() RXTXPort:MontitorThread:run() has_line_status_register_acess: Port does not support TIOCSERGETLSR init_threads: get eis init_threads: set eis init_threads: stop RXTXPort:RXTXPort(/dev/ttyUSB2) returns with fd = 8 RXTXPort:setSerialPortParams(38400 8 1 0) called RXTXPort:setSerialPortParams(38400 8 1 0) returning RXTXPort:getInputStream() called and returning Thu Apr 02 13:36:02 EDT 2009:TSerial[22]:Using Port:/dev/ttyUSB2 RXTXPort:getOutputStream() called and returning Thu Apr 02 13:36:02 EDT 2009:TSerial[22].Transmit:TN Entering RXTXPort:SerialOutputStream:write(4) writeArray() Leaving RXTXPort:SerialOutputStream:write(4) RXTXPort:SerialOutputStream:flush() enter RXTXPort:SerialOutputStream:flush() leave Thu Apr 02 13:36:02 EDT 2009:TSerial[22].Transmit:RV Entering RXTXPort:SerialOutputStream:write(4) writeArray() Leaving RXTXPort:SerialOutputStream:write(4) RXTXPort:SerialOutputStream:flush() enter RXTXPort:SerialInputStream:read(8192 0 8192) called ***FIRST PROCESS HANGS HERE ***THEN PROCEEDS AFTER SECOND PROCESS STARTS RXTXPort:SerialOutputStream:flush() leave Thu Apr 02 13:41:29 EDT 2009:TSerial[22].Transmit:IH9 Entering RXTXPort:SerialOutputStream:write(5) writeArray() Leaving RXTXPort:SerialOutputStream:write(5) RXTXPort:SerialOutputStream:flush() enter RXTXPort:SerialOutputStream:flush() leave Thu Apr 02 13:41:29 EDT 2009:TSerial[22].Transmit:IL11 ***END CAPTURE ***CAPTURE SECOND PROCESS FAILS OPEN [qms at qms4 ~]$ ./qms/ScriptFiles/startup.sh Thu Apr 02 13:41:27 EDT 2009:Setting Log File to:/home/qms/qms/QMS.log Thu Apr 02 13:41:27 EDT 2009:TSettings.HandleIni:ReUsing Ini file:/home/qms/qms/qms.properties WARNING: RXTX Version mismatch Jar version = RXTX-2.2pre2 native lib Version = RXTX-2.2pre3 fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB2: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB1: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB0: File exists fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB2: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB1: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB0: File exists fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile Thu Apr 02 13:41:30 EDT 2009:TIOBoard: java.io.IOException: java.io.IOException: TSerial[22]: Open Failed ***END CAPTURE -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090402/c66f8d70/attachment-0018.html From netbeans at gatworks.com Thu Apr 2 17:15:04 2009 From: netbeans at gatworks.com (U. George) Date: Thu, 02 Apr 2009 19:15:04 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: Message-ID: <49D546F8.20807@gatworks.com> > "z = new Zystem(Zystem.PRINT_MODE);" > Below is capture of the application with debugging enabled. It show > the application hang point, and the second application's printout at the > release point. (pre3 is the locally modified version of pre2) > Any suggestions on how to pin this down further? > Thanks, > +BillJ When perceived runability is hung, try a ^\ ( control \) on console. This gets the JVM to dump the stacks of all the java threads. If you know the thread that is stuck, then u can see what java statement its stuck at. From tjarvi at qbang.org Thu Apr 2 19:25:17 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 2 Apr 2009 19:25:17 -0600 (MDT) Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: <49D546F8.20807@gatworks.com> References: <49D546F8.20807@gatworks.com> Message-ID: On Thu, 2 Apr 2009, U. George wrote: >> "z = new Zystem(Zystem.PRINT_MODE);" >> Below is capture of the application with debugging enabled. It show >> the application hang point, and the second application's printout at the >> release point. (pre3 is the locally modified version of pre2) >> Any suggestions on how to pin this down further? >> Thanks, >> +BillJ > > When perceived runability is hung, try a ^\ ( control \) on console. > This gets the JVM to dump the stacks of all the java threads. > If you know the thread that is stuck, then u can see what java statement > its stuck at. I've also noticed some linux systems hanging with open/read/write and saw kacpid storms. I need to look at it more but did observe kacpid consuming a core and not returning to a normal state for a significant period of time. It was easy to observe from top sorted by CPU usage. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Apr 2 19:26:18 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 2 Apr 2009 19:26:18 -0600 (MDT) Subject: [Rxtx] Windows 64-bit support? In-Reply-To: <49D43979.4050702@bbs.darktech.org> References: <49D43979.4050702@bbs.darktech.org> Message-ID: On Thu, 2 Apr 2009, cowwoc wrote: > Hi, > > I'd like to run RXTX under the Windows 64-bit JVM. Are there plans > to release an official 64-bit version anytime soon? > It is in the prerelease and will be in the final release. I'm pushing it through as fast as I can in my free time. -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Thu Apr 2 22:57:34 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Fri, 03 Apr 2009 00:57:34 -0400 Subject: [Rxtx] Missing documentation In-Reply-To: References: <49D43979.4050702@bbs.darktech.org> Message-ID: <49D5973E.4050400@bbs.darktech.org> Hi, I noticed that RXTX 2.1 drops javax.comm support in favor of gnu.io. I have one major problem with this: the gui.io.* documentation is very poor. Many classes and methods have no Javadoc at all which makes them difficult to use. Please fix this for the final release. Thank you, Gili From alex.sas at freemail.hu Fri Apr 3 01:36:54 2009 From: alex.sas at freemail.hu (Sas Alex) Date: Fri, 3 Apr 2009 09:36:54 +0200 (CEST) Subject: [Rxtx] Serial port false reads Message-ID: Hi all, On Windows XP, using rxtx-2.1-7-r2 I have a program communicating on a serial line like the following (excerpt): { os.write(command); os.flush(); // Thread.sleep(period); // read response while(is.available() > 0) { is.read() } } If there is a sleep between the os.flush and the reading cycle the correct answer is received. Otherwise (sometimes) there are extra, erronous characters at the beginning of the answer, but the correct answer (according to the protocol) also arrives, afterwards. Is this a normal behaviour, one should wait before the read? If yes, is there a way to determine the minimum amount of time to wait for? Serial port params are: 9600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE. Thank you in advance, Alex ________________________________________________________ El?foglal?si akci? meghosszabb?tva! Korfui ?d?l?s m?r 56.910 Ft-t?l. http://www.budavartours.hu/gorogorszag/?utm_campaign=origo&utm_source=freemail_kimeno_090403&utm_medium=ct&utm_content=korfu_elofoglalasi_akcio#reg_Korfu -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090403/8f3650ea/attachment-0018.html From bill7007 at gmail.com Fri Apr 3 16:15:30 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Fri, 3 Apr 2009 18:15:30 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: <49D546F8.20807@gatworks.com> Message-ID: > When perceived runability is hung, try a ^\ ( control \) on console. >> This gets the JVM to dump the stacks of all the java threads. > > Good idea... A thread dump is below, it looks like only some system threads are in wait state which is probably normal. The "main" thread is stopped writing the first data out the serial port which should complete but its has stopped at: at gnu.io.RXTXPort.nativeDrain(Native Method) It show its state as runnable though. There is another thread, "SerialReader_22", that is waiting to read any data on the same port. I'll bring the app up under Netbeans debugger next. >> > I've also noticed some linux systems hanging with open/read/write and saw > kacpid storms. No CPU use going when it hangs, acts like a deadlock. THREAD DUMP AT HANG: Entering RXTXPort:SerialOutputStream:write(4) writeArray() Leaving RXTXPort:SerialOutputStream:write(4) RXTXPort:SerialOutputStream:flush() enter RXTXPort:SerialInputStream:read(8192 0 8192) called Full thread dump Java HotSpot(TM) Client VM (1.5.0_06-b05 mixed mode, sharing): "SerialReader_22" daemon prio=1 tid=0x087abf38 nid=0x3c8b runnable [0xb1a43000..0xb1a43f30] at gnu.io.RXTXPort.readArray(Native Method) at gnu.io.RXTXPort$SerialInputStream.read(RXTXPort.java:1454) - locked <0x88ca55b8> (a gnu.io.RXTXPort$SerialInputStream) at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:411) at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) - locked <0x88cab378> (a java.io.InputStreamReader) at java.io.InputStreamReader.read(InputStreamReader.java:167) at java.io.BufferedReader.fill(BufferedReader.java:136) at java.io.BufferedReader.readLine(BufferedReader.java:299) - locked <0x88cab378> (a java.io.InputStreamReader) at java.io.BufferedReader.readLine(BufferedReader.java:362) at qms.TSerialPort$SerialRead.run(TSerialPort.java:268) at java.lang.Thread.run(Thread.java:595) "Thread-1" prio=1 tid=0x08a43360 nid=0x3c8a runnable [0xb1ac4000..0xb1ac4db0] at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1641) "AWT-XAWT" daemon prio=1 tid=0x08acc848 nid=0x3c87 runnable [0xb1b45000..0xb1b45e30] at sun.awt.X11.XToolkit.waitForEvents(Native Method) at sun.awt.X11.XToolkit.run(XToolkit.java:463) at sun.awt.X11.XToolkit.run(XToolkit.java:438) at java.lang.Thread.run(Thread.java:595) "Java2D Disposer" daemon prio=1 tid=0x08ab9d30 nid=0x3c86 in Object.wait() [0xb1bc6000..0xb1bc70b0] at java.lang.Object.wait(Native Method) - waiting on <0x8917b110> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:116) - locked <0x8917b110> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:132) at sun.java2d.Disposer.run(Disposer.java:107) at java.lang.Thread.run(Thread.java:595) "Low Memory Detector" daemon prio=1 tid=0x087bea68 nid=0x3c84 runnable [0x00000000..0x00000000] "CompilerThread0" daemon prio=1 tid=0x087bd4c0 nid=0x3c83 waiting on condition [0x00000000..0xb23a7a18] "Signal Dispatcher" daemon prio=1 tid=0x087bc520 nid=0x3c82 runnable [0x00000000..0x00000000] "Finalizer" daemon prio=1 tid=0x087b5710 nid=0x3c81 in Object.wait() [0xb26a9000..0xb26a9f30] at java.lang.Object.wait(Native Method) - waiting on <0x8914a770> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:116) - locked <0x8914a770> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:132) at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159) "Reference Handler" daemon prio=1 tid=0x087b49c8 nid=0x3c80 in Object.wait() [0xb272a000..0xb272adb0] at java.lang.Object.wait(Native Method) - waiting on <0x8914a7f0> (a java.lang.ref.Reference$Lock) at java.lang.Object.wait(Object.java:474) at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116) - locked <0x8914a7f0> (a java.lang.ref.Reference$Lock) "main" prio=1 tid=0x08777b88 nid=0x3c7e runnable [0xbffa7000..0xbffa74f8] at gnu.io.RXTXPort.nativeDrain(Native Method) at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1248) at qms.TSerialPort.Transmit(TSerialPort.java:192) - locked <0x88c99a68> (a qms.TSerialPort) at qms.TIOBoard.GetIOBoardVersion(TIOBoard.java:168) at qms.TIOBoard.(TIOBoard.java:73) at qms.TQMS.(TQMS.java:47) at qms.MainForm.(MainForm.java:2076) at qms.MainForm.main(MainForm.java:2099) "VM Thread" prio=1 tid=0x087b1e20 nid=0x3c7f runnable "VM Periodic Task Thread" prio=1 tid=0x087bff50 nid=0x3c85 waiting on condition -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090403/20b7bca4/attachment-0017.html From Martin.Oberhuber at windriver.com Fri Apr 3 16:23:43 2009 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Sat, 4 Apr 2009 00:23:43 +0200 Subject: [Rxtx] Missing documentation In-Reply-To: <49D5973E.4050400@bbs.darktech.org> References: <49D43979.4050702@bbs.darktech.org> <49D5973E.4050400@bbs.darktech.org> Message-ID: <460801A4097E3D4CA04CC64EE648584809C8BD6F@ism-mail03.corp.ad.wrs.com> Hello Gili, The classes in the gnu.io namespace are designed to work exactly as their counterparts in the javax.comm namespace. Therefore, if you just take the javax.comm Javadocs that's what you want. Unfortunately I don't think we can just copy & paste the javax.comm Javadocs into RXTX due to license restrictions. I guess that's the main reason why RXTX is not (yet) Javadoc'd as extensively as it should be. Actually, writing Javadocs from scratch WITHOUT referencing the wording of the Sun Javadocs is not that easy. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of cowwoc > Sent: Freitag, 03. April 2009 06:58 > To: rxtx at qbang.org > Subject: [Rxtx] Missing documentation > > Hi, > > I noticed that RXTX 2.1 drops javax.comm support in favor > of gnu.io. > I have one major problem with this: the gui.io.* > documentation is very > poor. Many classes and methods have no Javadoc at all which > makes them > difficult to use. Please fix this for the final release. > > Thank you, > Gili > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Fri Apr 3 16:54:50 2009 From: netbeans at gatworks.com (U. George) Date: Fri, 03 Apr 2009 18:54:50 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: <49D546F8.20807@gatworks.com> Message-ID: <49D693BA.8060909@gatworks.com> I would have tried 2 or 3 "^\" . If things are stuck, then all will be at same 'java' instruction. If thread is moving, then one of the snapshots would be different. I *think* flushing/draining wont return until the kernel buffers to device have been accepted by device. Stuck/paused device? Bill Johnson wrote: > > > > > When perceived runability is hung, try a ^\ ( control \) on console. > This gets the JVM to dump the stacks of all the java threads. > > > Good idea... A thread dump is below, it looks like only some system > threads are in wait state which is prob From cowwoc at bbs.darktech.org Fri Apr 3 17:45:09 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Fri, 03 Apr 2009 19:45:09 -0400 Subject: [Rxtx] Missing documentation In-Reply-To: <460801A4097E3D4CA04CC64EE648584809C8BD6F@ism-mail03.corp.ad.wrs.com> References: <49D43979.4050702@bbs.darktech.org> <49D5973E.4050400@bbs.darktech.org> <460801A4097E3D4CA04CC64EE648584809C8BD6F@ism-mail03.corp.ad.wrs.com> Message-ID: <49D69F85.3030804@bbs.darktech.org> You could always send Sun a formal email and ask for permission to copy their Javadoc. I doubt they would give you problems. Gili Oberhuber, Martin wrote: > Hello Gili, > > The classes in the gnu.io namespace are designed to work exactly > as their counterparts in the javax.comm namespace. Therefore, > if you just take the javax.comm Javadocs that's what you want. > > Unfortunately I don't think we can just copy & paste the > javax.comm Javadocs into RXTX due to license restrictions. > > I guess that's the main reason why RXTX is not (yet) Javadoc'd > as extensively as it should be. Actually, writing Javadocs > from scratch WITHOUT referencing the wording of the Sun > Javadocs is not that easy. > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] >> On Behalf Of cowwoc >> Sent: Freitag, 03. April 2009 06:58 >> To: rxtx at qbang.org >> Subject: [Rxtx] Missing documentation >> >> Hi, >> >> I noticed that RXTX 2.1 drops javax.comm support in favor >> of gnu.io. >> I have one major problem with this: the gui.io.* >> documentation is very >> poor. Many classes and methods have no Javadoc at all which >> makes them >> difficult to use. Please fix this for the final release. >> >> Thank you, >> Gili >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> From cowwoc at bbs.darktech.org Sat Apr 4 15:13:38 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sat, 04 Apr 2009 17:13:38 -0400 Subject: [Rxtx] Java5 support Message-ID: <49D7CD82.1040904@bbs.darktech.org> Now that you dropped javax.comm support, how about improving the API by replacing Enumation by Iterator, int by enum, and using Generics? It would improve the usability of the API. Gili From cowwoc at bbs.darktech.org Sat Apr 4 16:12:13 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sat, 04 Apr 2009 18:12:13 -0400 Subject: [Rxtx] RXTX Version mismatch in 2.2pre2 Message-ID: <49D7DB3D.5040008@bbs.darktech.org> When using RXTX-2.2pre2 I always get the following message: WARNING: RXTX Version mismatch Jar version = RXTX-2.2pre1 native lib Version = RXTX-2.2pre2 I have double checked that I am using the correct Jar file. Is this a known bug in pre2? Gili From tjarvi at qbang.org Sat Apr 4 16:48:53 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Apr 2009 16:48:53 -0600 (MDT) Subject: [Rxtx] RXTX Version mismatch in 2.2pre2 In-Reply-To: <49D7DB3D.5040008@bbs.darktech.org> References: <49D7DB3D.5040008@bbs.darktech.org> Message-ID: > When using RXTX-2.2pre2 I always get the following message: > > WARNING: RXTX Version mismatch > Jar version = RXTX-2.2pre1 > native lib Version = RXTX-2.2pre2 > Yep. You should still be able to test it. -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Sat Apr 4 16:50:43 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sat, 04 Apr 2009 18:50:43 -0400 Subject: [Rxtx] RXTX Version mismatch in 2.2pre2 In-Reply-To: References: <49D7DB3D.5040008@bbs.darktech.org> Message-ID: <49D7E443.9070404@bbs.darktech.org> In other words this is a known bug that will be fixed in the final version? Gili Trent Jarvi wrote: > > >> When using RXTX-2.2pre2 I always get the following message: >> >> WARNING: RXTX Version mismatch >> Jar version = RXTX-2.2pre1 >> native lib Version = RXTX-2.2pre2 >> > > Yep. > > You should still be able to test it. > > -- > Trent Jarvi > tjarvi at qbang.org From cowwoc at bbs.darktech.org Sat Apr 4 16:57:34 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sat, 04 Apr 2009 18:57:34 -0400 Subject: [Rxtx] IOException: Underlying input stream returned zero bytes Message-ID: <49D7E5DE.2050405@bbs.darktech.org> Hi, There seems to be a bug in RXTX 2.2pre2's handling of InputStream timeouts. If you open a serial port without ever invoking enableReceiveTimeout() then invoking InputStream.read() will always return 0 bytes right away. If you wrap the InputStream and invoke BufferedReader.readline() you will get the following exception: java.io.IOException: Underlying input stream returned zero bytes at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:268) [na:1.6.0_14-ea] at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:306) [na:1.6.0_14-ea] at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:158) [na:1.6.0_14-ea] at java.io.InputStreamReader.read(InputStreamReader.java:167) [na:1.6.0_14-ea] at java.io.BufferedReader.fill(BufferedReader.java:136) [na:1.6.0_14-ea] at java.io.BufferedReader.readLine(BufferedReader.java:299) [na:1.6.0_14-ea] at java.io.BufferedReader.readLine(BufferedReader.java:362) [na:1.6.0_14-ea] [snip] If you enable a timeout, the exception will only occur after the timeout expires. In short, it looks like RXTX is using a default timeout of zero (I am expecting it to block forever). It looks like other people have run into this as well: http://forums.sun.com/thread.jspa?threadID=5165346&start=10&tstart=0 Please confirm whether this is a known bug. Thank you, Gili From tjarvi at qbang.org Sat Apr 4 17:27:19 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 4 Apr 2009 17:27:19 -0600 (MDT) Subject: [Rxtx] IOException: Underlying input stream returned zero bytes In-Reply-To: <49D7E5DE.2050405@bbs.darktech.org> References: <49D7E5DE.2050405@bbs.darktech.org> Message-ID: On Sat, 4 Apr 2009, cowwoc wrote: > Hi, > > There seems to be a bug in RXTX 2.2pre2's handling of InputStream > timeouts. If you open a serial port without ever invoking > enableReceiveTimeout() then invoking InputStream.read() will always > return 0 bytes right away. If you wrap the InputStream and invoke > BufferedReader.readline() you will get the following exception: > > java.io.IOException: Underlying input stream returned zero bytes > at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:268) > [na:1.6.0_14-ea] > at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:306) > [na:1.6.0_14-ea] > at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:158) > [na:1.6.0_14-ea] > at java.io.InputStreamReader.read(InputStreamReader.java:167) > [na:1.6.0_14-ea] > at java.io.BufferedReader.fill(BufferedReader.java:136) > [na:1.6.0_14-ea] > at java.io.BufferedReader.readLine(BufferedReader.java:299) > [na:1.6.0_14-ea] > at java.io.BufferedReader.readLine(BufferedReader.java:362) > [na:1.6.0_14-ea] > [snip] > > If you enable a timeout, the exception will only occur after the > timeout expires. In short, it looks like RXTX is using a default timeout > of zero (I am expecting it to block forever). It looks like other people > have run into this as well: > http://forums.sun.com/thread.jspa?threadID=5165346&start=10&tstart=0 > > Please confirm whether this is a known bug. > Hi Gili I've known about it but was not sure if it was a bug or not. It looks like we can treat it as a bug if nio is throwing an exception. Timeout and Thresholds are well documented in javax.comm but I didn't recall seeing defaults. For that reason, I've encouraged people to set the threshold and timeout to what they expect. Another note about InputStream.read(void): I noticed that I don't use that function at all while looking at code coverage results. Keep your eye out for additional issues. -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Sat Apr 4 19:03:29 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sat, 04 Apr 2009 21:03:29 -0400 Subject: [Rxtx] IOException: Underlying input stream returned zero bytes In-Reply-To: References: <49D7E5DE.2050405@bbs.darktech.org> Message-ID: <49D80361.7020801@bbs.darktech.org> Trent Jarvi wrote: > For that reason, I've encouraged people to set the threshold and timeout > to what they expect. It doesn't help. There doesn't seem to be a way to disable the timeout, even if you invoke disableReceiveTimeout() explicitly. Let me know when you put in a fix and I will test it. Thanks, Gili From cowwoc at bbs.darktech.org Sat Apr 4 23:27:25 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 01:27:25 -0400 Subject: [Rxtx] Crash in termios.c:892 Message-ID: <49D8413D.7040105@bbs.darktech.org> I can reproduce a crash in RXTX 2.2 pre2 100% of the time using my application code, but I can't seem to bring it down to a minimal testcase. Here is what I see: - thread begins running - open com1 - close com1 - open com5 - leave com5 open - thread shuts down - repeat the same process in a new thread - crash occurs when trying to open com1. Crash disappears if I close() com5 in the previous thread. The output window contains the following: # # A fatal error has been detected by the Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x05475cf6, pid=6064, tid=5436 # # JRE version: 6.0_14-b04 # Java VM: Java HotSpot(TM) Client VM (14.0-b13 mixed mode, sharing windows-x86 ) # Problematic frame: # C [rxtxSerial.dll+0x5cf6] # # An error report file with more information is saved as: # C:\Users\Gili\Documents\foobar\source\hs_err_pid6064.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp Error 0x5 at ..\src\termios.c(892): Access is denied. # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # Please let me know if the crash dump is enough to track down this bug. Thank you, Gili -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: hs_err_pid6064.log Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20090405/7133a1ce/attachment-0014.pl From cowwoc at bbs.darktech.org Sun Apr 5 00:24:19 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 02:24:19 -0400 Subject: [Rxtx] SerialPort.getName() is wrong Message-ID: <49D84E93.7050606@bbs.darktech.org> Sorry for all these emails but I keep on running into more issues. Here is what I noticed: - CommPortIdentifier.getPortIdentifier("COM5") returns a CommPortIdentifier where getName() == "COM5" - If, however, you invoke CommPortIdentifier.open() you get back a SerialPort where SerialPort.getName() is "//./COM5" I am expecting the name to remain consistent. "//./COM5" looks like an implementation detail and (as far as I can tell) it can't be used as an argument for any API method so it is somewhat useless. If getName() were to return "COM5" I could at least use it to get back the original CommPortIdentifier or compare against "known names" such as "COMx" or "LPTx". What do you think? Gili From tjarvi at qbang.org Sun Apr 5 10:18:42 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Apr 2009 10:18:42 -0600 (MDT) Subject: [Rxtx] SerialPort.getName() is wrong In-Reply-To: <49D84E93.7050606@bbs.darktech.org> References: <49D84E93.7050606@bbs.darktech.org> Message-ID: On Sun, 5 Apr 2009, cowwoc wrote: > > Sorry for all these emails but I keep on running into more issues. > Here is what I noticed: > > - CommPortIdentifier.getPortIdentifier("COM5") returns a > CommPortIdentifier where getName() == "COM5" > - If, however, you invoke CommPortIdentifier.open() you get back a > SerialPort where SerialPort.getName() is "//./COM5" > > I am expecting the name to remain consistent. "//./COM5" looks like > an implementation detail and (as far as I can tell) it can't be used as > an argument for any API method so it is somewhat useless. If getName() > were to return "COM5" I could at least use it to get back the original > CommPortIdentifier or compare against "known names" such as "COMx" or > "LPTx". What do you think? > Sure. If it itches enough you should be able to fix this in RXTXCommDriver.java. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Apr 5 10:27:58 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Apr 2009 10:27:58 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D8413D.7040105@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> Message-ID: On Sun, 5 Apr 2009, cowwoc wrote: > > I can reproduce a crash in RXTX 2.2 pre2 100% of the time using my > application code, but I can't seem to bring it down to a minimal testcase. > Here is what I see: > > - thread begins running > - open com1 > - close com1 > - open com5 > - leave com5 open > - thread shuts down > - repeat the same process in a new thread > - crash occurs when trying to open com1. Crash disappears if I close() com5 > in the previous thread. > > The output window contains the following: > > # > # A fatal error has been detected by the Java Runtime Environment: > # > # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x05475cf6, pid=6064, > tid=5436 > # > # JRE version: 6.0_14-b04 > # Java VM: Java HotSpot(TM) Client VM (14.0-b13 mixed mode, sharing > windows-x86 ) > # Problematic frame: > # C [rxtxSerial.dll+0x5cf6] > # > # An error report file with more information is saved as: > # C:\Users\Gili\Documents\foobar\source\hs_err_pid6064.log > # > # If you would like to submit a bug report, please visit: > # http://java.sun.com/webapps/bugreport/crash.jsp > Error 0x5 at ..\src\termios.c(892): Access is denied. > > > # The crash happened outside the Java Virtual Machine in native code. > # See problematic frame for where to report the bug. > # > > Please let me know if the crash dump is enough to track down this bug. > Hi Gili, You are responsible for cleaning up the serial ports when using threads. That said, if the thread did shut down, finalize should have been called if you are not passing the object around. See RXTXPort.java. protected void finalize() { if (debug) z.reportln( "RXTXPort:finalize()"); if( fd > 0 ) { if (debug) z.reportln( "RXTXPort:calling close()"); close(); } z.finalize(); } The exception is interesting. This is on Vista? Usually it just gives an open error when another process has the port. -- Trent Jarvi tjarvi at mathworks.com From cowwoc at bbs.darktech.org Sun Apr 5 10:35:55 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 12:35:55 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: References: <49D8413D.7040105@bbs.darktech.org> Message-ID: <49D8DDEB.5010908@bbs.darktech.org> Trent Jarvi wrote: > You are responsible for cleaning up the serial ports when using threads. > That said, if the thread did shut down, finalize should have been called > if you are not passing the object around. See RXTXPort.java. > > protected void finalize() > { > if (debug) > z.reportln( "RXTXPort:finalize()"); > if( fd > 0 ) > { > if (debug) > z.reportln( "RXTXPort:calling close()"); > close(); > } > z.finalize(); > } Two points: 1) One should never rely on finalizers because they may never run. 2) RXTX shouldn't cause the entire JVM to crash if I misuse the API. The native code should recover more gracefully. > The exception is interesting. This is on Vista? Usually it just gives > an open error when another process has the port. Yes, this is on Vista 64-bit. I'd really like to see this bug fixed. Is this code compilable under Visual Studio? If so, I can debug the problem on my end and send you a patch. Thanks, Gili From cowwoc at bbs.darktech.org Sun Apr 5 10:36:20 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 12:36:20 -0400 Subject: [Rxtx] SerialPort.getName() is wrong In-Reply-To: References: <49D84E93.7050606@bbs.darktech.org> Message-ID: <49D8DE04.6030306@bbs.darktech.org> Trent Jarvi wrote: >> I am expecting the name to remain consistent. "//./COM5" looks like >> an implementation detail and (as far as I can tell) it can't be used as >> an argument for any API method so it is somewhat useless. If getName() >> were to return "COM5" I could at least use it to get back the original >> CommPortIdentifier or compare against "known names" such as "COMx" or >> "LPTx". What do you think? >> > > Sure. > > If it itches enough you should be able to fix this in RXTXCommDriver.java. I'm not sure I understand. Are you saying that if I submit a patch you will commit it? Gili From tjarvi at qbang.org Sun Apr 5 10:46:23 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Apr 2009 10:46:23 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D8DDEB.5010908@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> Message-ID: On Sun, 5 Apr 2009, cowwoc wrote: > Trent Jarvi wrote: >> You are responsible for cleaning up the serial ports when using threads. >> That said, if the thread did shut down, finalize should have been called if >> you are not passing the object around. See RXTXPort.java. >> >> protected void finalize() >> { >> if (debug) >> z.reportln( "RXTXPort:finalize()"); >> if( fd > 0 ) >> { >> if (debug) >> z.reportln( "RXTXPort:calling close()"); >> close(); >> } >> z.finalize(); >> } > > Two points: > > 1) One should never rely on finalizers because they may never run. > 2) RXTX shouldn't cause the entire JVM to crash if I misuse the API. The > native code should recover more gracefully. > >> The exception is interesting. This is on Vista? Usually it just gives an >> open error when another process has the port. > > Yes, this is on Vista 64-bit. I'd really like to see this bug fixed. > Is this code compilable under Visual Studio? If so, I can debug the problem > on my end and send you a patch. > It will compile with the msvc cl.exe and nmake. See Makefile.msvc in the top level directory. You will need to adjust the JAVA_HOME variable. Also use the MSVC command prompt for x86_64 so cl and nmake are on your path. All the best, -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Apr 5 10:49:10 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Apr 2009 10:49:10 -0600 (MDT) Subject: [Rxtx] SerialPort.getName() is wrong In-Reply-To: <49D8DE04.6030306@bbs.darktech.org> References: <49D84E93.7050606@bbs.darktech.org> <49D8DE04.6030306@bbs.darktech.org> Message-ID: On Sun, 5 Apr 2009, cowwoc wrote: > Trent Jarvi wrote: >>> I am expecting the name to remain consistent. "//./COM5" looks like >>> an implementation detail and (as far as I can tell) it can't be used as >>> an argument for any API method so it is somewhat useless. If getName() >>> were to return "COM5" I could at least use it to get back the original >>> CommPortIdentifier or compare against "known names" such as "COMx" or >>> "LPTx". What do you think? >>> >> >> Sure. >> >> If it itches enough you should be able to fix this in RXTXCommDriver.java. > > I'm not sure I understand. Are you saying that if I submit a patch > you will commit it? > Hi Gili, Post a patch here and if nobody complains, we will commit it and give you credit. Yep. Other issues like changing the API to use java5 that may break existing apps are likely to run into objections but bug fixes usually get fixed just as you mention. -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Sun Apr 5 10:55:07 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 12:55:07 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> Message-ID: <49D8E26B.2040705@bbs.darktech.org> Trent Jarvi wrote: > It will compile with the msvc cl.exe and nmake. See Makefile.msvc in > the top level directory. You will need to adjust the JAVA_HOME > variable. Also use the MSVC command prompt for x86_64 so cl and nmake > are on your path. This is very odd. The CVS version of the code does not contain this file. Do you keep the latest code somewhere else? Gili From cowwoc at bbs.darktech.org Sun Apr 5 11:01:58 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 13:01:58 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D8E26B.2040705@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> Message-ID: <49D8E406.10708@bbs.darktech.org> cowwoc wrote: > Trent Jarvi wrote: >> It will compile with the msvc cl.exe and nmake. See Makefile.msvc in >> the top level directory. You will need to adjust the JAVA_HOME >> variable. Also use the MSVC command prompt for x86_64 so cl and nmake >> are on your path. > > This is very odd. The CVS version of the code does not contain this > file. Do you keep the latest code somewhere else? Okay I figured it out. CVS head is out of date, the "commapi-0-0-1" revision contains the correct files. Gili From tjarvi at qbang.org Sun Apr 5 11:05:43 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Apr 2009 11:05:43 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D8E26B.2040705@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> Message-ID: CVS HEAD is currently the rxtx 2.0 code. A branch was created long ago for 'experimental' gnu.io work. It just happens that the branch is what everyone uses now. checkout -r commapi-0-0-1 rxtx-devel will get the branch On Sun, 5 Apr 2009, cowwoc wrote: > Trent Jarvi wrote: >> It will compile with the msvc cl.exe and nmake. See Makefile.msvc in the >> top level directory. You will need to adjust the JAVA_HOME variable. Also >> use the MSVC command prompt for x86_64 so cl and nmake are on your path. > > This is very odd. The CVS version of the code does not contain this > file. Do you keep the latest code somewhere else? > > Gili > From cowwoc at bbs.darktech.org Sun Apr 5 14:50:47 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 16:50:47 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> Message-ID: <49D919A7.1070806@bbs.darktech.org> Okay, I tracked down the crash. It's being caused by YACK() using a 80-character buffer. The error message is longer than 80 characters, so _snprintf_s() crashes to avoid a buffer overflow. Please apply the attached patch and add the zipped up Visual Studio project directory. It's not perfect yet but it's a good start. Gili Trent Jarvi wrote: > > CVS HEAD is currently the rxtx 2.0 code. A branch was created long > ago for 'experimental' gnu.io work. It just happens that the branch > is what everyone uses now. > > checkout -r commapi-0-0-1 rxtx-devel > > will get the branch > > On Sun, 5 Apr 2009, cowwoc wrote: > >> Trent Jarvi wrote: >>> It will compile with the msvc cl.exe and nmake. See Makefile.msvc >>> in the top level directory. You will need to adjust the JAVA_HOME >>> variable. Also use the MSVC command prompt for x86_64 so cl and >>> nmake are on your path. >> >> This is very odd. The CVS version of the code does not contain >> this file. Do you keep the latest code somewhere else? >> >> Gili >> -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx-devel.patch Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20090405/d9b82962/attachment-0013.pl -------------- next part -------------- A non-text attachment was scrubbed... Name: Win32.zip Type: application/octet-stream Size: 17764 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20090405/d9b82962/attachment-0015.obj From cowwoc at bbs.darktech.org Sun Apr 5 15:22:01 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sun, 05 Apr 2009 17:22:01 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D919A7.1070806@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> <49D919A7.1070806@bbs.darktech.org> Message-ID: <49D920F9.6080702@bbs.darktech.org> My mistake. The problem in YACK is real, but it isn't the real cause of the crash. The crash is caused by termios.c line 1099: index->prev->next = port; because in my case "index->prev==0". I think the bug is that the code assumes that index will contain a minimum of two entries if we're inserting a previously closed fd. In my case, it only contains one. I'm not sure why you have this code branch (as opposed to appending to the end of index). Please take a look. Thanks, Gili cowwoc wrote: > > Okay, I tracked down the crash. It's being caused by YACK() using a > 80-character buffer. The error message is longer than 80 characters, so > _snprintf_s() crashes to avoid a buffer overflow. > > Please apply the attached patch and add the zipped up Visual Studio > project directory. It's not perfect yet but it's a good start. > > Gili > > Trent Jarvi wrote: >> >> CVS HEAD is currently the rxtx 2.0 code. A branch was created long >> ago for 'experimental' gnu.io work. It just happens that the branch >> is what everyone uses now. >> >> checkout -r commapi-0-0-1 rxtx-devel >> >> will get the branch >> >> On Sun, 5 Apr 2009, cowwoc wrote: >> >>> Trent Jarvi wrote: >>>> It will compile with the msvc cl.exe and nmake. See Makefile.msvc >>>> in the top level directory. You will need to adjust the JAVA_HOME >>>> variable. Also use the MSVC command prompt for x86_64 so cl and >>>> nmake are on your path. >>> >>> This is very odd. The CVS version of the code does not contain >>> this file. Do you keep the latest code somewhere else? >>> >>> Gili >>> From tjarvi at qbang.org Sun Apr 5 16:13:27 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 5 Apr 2009 16:13:27 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D920F9.6080702@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> <49D919A7.1070806@bbs.darktech.org> <49D920F9.6080702@bbs.darktech.org> Message-ID: Hi Gili, Are you using the cvs version? I thought we fixed the linked list issues. A solution was posted to the list. Let me look at work tomorrow to see what I have. On Sun, 5 Apr 2009, cowwoc wrote: > > My mistake. The problem in YACK is real, but it isn't the real cause > of the crash. The crash is caused by termios.c line 1099: > > index->prev->next = port; > > because in my case "index->prev==0". I think the bug is that the code > assumes that index will contain a minimum of two entries if we're inserting a > previously closed fd. In my case, it only contains one. > > I'm not sure why you have this code branch (as opposed to appending > to the end of index). Please take a look. > > Thanks, > Gili > > cowwoc wrote: >> >> Okay, I tracked down the crash. It's being caused by YACK() using a >> 80-character buffer. The error message is longer than 80 characters, so >> _snprintf_s() crashes to avoid a buffer overflow. >> >> Please apply the attached patch and add the zipped up Visual Studio >> project directory. It's not perfect yet but it's a good start. >> >> Gili >> >> Trent Jarvi wrote: >>> >>> CVS HEAD is currently the rxtx 2.0 code. A branch was created long ago >>> for 'experimental' gnu.io work. It just happens that the branch is what >>> everyone uses now. >>> >>> checkout -r commapi-0-0-1 rxtx-devel >>> >>> will get the branch >>> >>> On Sun, 5 Apr 2009, cowwoc wrote: >>> >>>> Trent Jarvi wrote: >>>>> It will compile with the msvc cl.exe and nmake. See Makefile.msvc in >>>>> the top level directory. You will need to adjust the JAVA_HOME >>>>> variable. Also use the MSVC command prompt for x86_64 so cl and nmake >>>>> are on your path. >>>> >>>> This is very odd. The CVS version of the code does not contain this >>>> file. Do you keep the latest code somewhere else? >>>> >>>> Gili >>>> > From ilkka at myller.com Sun Apr 5 23:58:08 2009 From: ilkka at myller.com (Ilkka Myller) Date: Mon, 6 Apr 2009 08:58:08 +0300 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> <49D919A7.1070806@bbs.darktech.org> <49D920F9.6080702@bbs.darktech.org> Message-ID: <19779C97-E0C7-4E3D-B715-F84F50F00CE6@myller.com> Hi all, I've already submitted the patch to fix this issue in february: http://mailman.qbang.org/pipermail/rxtx/2009-February/3989441.html The patch fixes the mentioned doubly linked list handling in termios.c -- I Trent Jarvi kirjoitti 6.4.2009 kello 1.13: > > Hi Gili, > > Are you using the cvs version? I thought we fixed the linked list > issues. > A solution was posted to the list. Let me look at work tomorrow to > see > what I have. > > > > On Sun, 5 Apr 2009, cowwoc wrote: > >> >> My mistake. The problem in YACK is real, but it isn't the real cause >> of the crash. The crash is caused by termios.c line 1099: >> >> index->prev->next = port; >> >> because in my case "index->prev==0". I think the bug is that the >> code >> assumes that index will contain a minimum of two entries if we're >> inserting a >> previously closed fd. In my case, it only contains one. >> >> I'm not sure why you have this code branch (as opposed to appending >> to the end of index). Please take a look. >> >> Thanks, >> Gili >> >> cowwoc wrote: >>> >>> Okay, I tracked down the crash. It's being caused by YACK() >>> using a >>> 80-character buffer. The error message is longer than 80 >>> characters, so >>> _snprintf_s() crashes to avoid a buffer overflow. >>> >>> Please apply the attached patch and add the zipped up Visual >>> Studio >>> project directory. It's not perfect yet but it's a good start. >>> >>> Gili >>> >>> Trent Jarvi wrote: >>>> >>>> CVS HEAD is currently the rxtx 2.0 code. A branch was created >>>> long ago >>>> for 'experimental' gnu.io work. It just happens that the branch >>>> is what >>>> everyone uses now. >>>> >>>> checkout -r commapi-0-0-1 rxtx-devel >>>> >>>> will get the branch >>>> >>>> On Sun, 5 Apr 2009, cowwoc wrote: >>>> >>>>> Trent Jarvi wrote: >>>>>> It will compile with the msvc cl.exe and nmake. See >>>>>> Makefile.msvc in >>>>>> the top level directory. You will need to adjust the JAVA_HOME >>>>>> variable. Also use the MSVC command prompt for x86_64 so cl and >>>>>> nmake >>>>>> are on your path. >>>>> >>>>> This is very odd. The CVS version of the code does not >>>>> contain this >>>>> file. Do you keep the latest code somewhere else? >>>>> >>>>> Gili >>>>> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Steffen.DETTMER at ingenico.com Mon Apr 6 02:53:47 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 6 Apr 2009 10:53:47 +0200 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D919A7.1070806@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> <49D919A7.1070806@bbs.darktech.org> Message-ID: <20090406085347.GM8289@elberon.bln.de.ingenico.com> Hi, just two minor details, first about the errno change, I though #include extern int errno; is correct (POSIX.1) - why this change? second about the log message, I think the maximum length could be limited and the return value of malloc must be checked for != NULL before using. Should it be _snprintf_s( message, 80, _TRUNCATE, "Error 0x%x at %s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); (I know that MS-CRT _snprintf does not guarantee to have a final EOS, but I think _snprintf_s with _TRUNCATE does so?). If it is known that truncation may happen maybe sizeof[message] could be increased; maybe using some %.20s could be used avoiding __FILE__ including big pathes to a message where all the message had been cut-off. To have it portable I think it could be: /* generally: */ #if defined(_MSC_VER) # define snprintf _snprintf #endif snprintf(message, sizeof(message), "Error 0x%x at %.20s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); message[sizeof(message)-1] = '\0'; /* needed for MS CRT snprintf */ (for length and size parameter I think size_t could be an option, but on several platforms, including MS-CRT and older glibc, there is no %z, unfortunately) oki, Steffen * cowwoc wrote on Sun, Apr 05, 2009 at 16:50 -0400: > > Okay, I tracked down the crash. It's being caused by YACK() using a > 80-character buffer. The error message is longer than 80 characters, so > _snprintf_s() crashes to avoid a buffer overflow. > > Please apply the attached patch and add the zipped up Visual Studio > project directory. It's not perfect yet but it's a good start. > > Gili > > Trent Jarvi wrote: > > > >CVS HEAD is currently the rxtx 2.0 code. A branch was created long > >ago for 'experimental' gnu.io work. It just happens that the branch > >is what everyone uses now. > > > >checkout -r commapi-0-0-1 rxtx-devel > > > >will get the branch > > > >On Sun, 5 Apr 2009, cowwoc wrote: > > > >>Trent Jarvi wrote: > >>>It will compile with the msvc cl.exe and nmake. See Makefile.msvc > >>>in the top level directory. You will need to adjust the JAVA_HOME > >>>variable. Also use the MSVC command prompt for x86_64 so cl and > >>>nmake are on your path. > >> > >> This is very odd. The CVS version of the code does not contain > >>this file. Do you keep the latest code somewhere else? > >> > >>Gili > >> > Index: ParallelImp.c > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/ParallelImp.c,v > retrieving revision 1.15.2.36 > diff -u -r1.15.2.36 ParallelImp.c > --- ParallelImp.c 11 Feb 2009 01:04:19 -0000 1.15.2.36 > +++ ParallelImp.c 5 Apr 2009 17:55:23 -0000 > @@ -119,7 +119,7 @@ > # include > #endif > > -extern int errno; > +_CRTIMP extern int * __cdecl _errno(void); > > #include "ParallelImp.h" > > @@ -181,8 +181,6 @@ > > #if defined (WIN32) > > -#define CTL_CODE( DeviceType, Function, Method, Access ) (((DeviceType) << 16) | ((Access) << 14) | ((Function) << 2) | (Method)) > - > #define FILE_DEVICE_PARALLEL_PORT 0x00000016 > #define METHOD_BUFFERED 0 > #define FILE_ANY_ACCESS 0 > @@ -253,7 +251,6 @@ > jobject jobj) > { > int fd = get_java_var( env, jobj,"fd","I" ); > - int status; > #if defined (__linux__) > ioctl(fd, LPGETSTATUS, &status); > #elif defined (WIN32) > Index: SerialImp.c > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v > retrieving revision 1.46.2.203 > diff -u -r1.46.2.203 SerialImp.c > --- SerialImp.c 19 Mar 2009 03:27:48 -0000 1.46.2.203 > +++ SerialImp.c 5 Apr 2009 17:49:48 -0000 > @@ -147,7 +147,7 @@ > #include > #endif /* LIBLOCKDEV */ > > -extern int errno; > +_CRTIMP extern int * __cdecl _errno(void); > > #include "SerialImp.h" > > Index: termios.c > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/termios.c,v > retrieving revision 1.9.2.62 > diff -u -r1.9.2.62 termios.c > --- termios.c 13 Jan 2009 03:08:55 -0000 1.9.2.62 > +++ termios.c 5 Apr 2009 17:54:09 -0000 > @@ -88,7 +88,7 @@ > #define SIGIO 0 > > int my_errno; > -extern int errno; > +_CRTIMP extern int * __cdecl _errno(void); > struct termios_list > { > char filename[80]; > @@ -1350,7 +1350,7 @@ > In that case use EAGAIN. See SerialImp.c:testRead() > ----------------------------------------------------------*/ > > -int serial_read( int fd, void *vb, int size ) > +int serial_read( int fd, void *vb, unsigned int size ) > { > long start, now; > unsigned long nBytes = 0, total = 0, error; > Index: win32termios.h > =================================================================== > RCS file: /usr/local/cvsroot/rxtx-devel/src/win32termios.h,v > retrieving revision 1.5.2.34 > diff -u -r1.5.2.34 win32termios.h > --- win32termios.h 5 Feb 2009 01:25:05 -0000 1.5.2.34 > +++ win32termios.h 5 Apr 2009 20:29:30 -0000 > @@ -60,6 +60,7 @@ > #include > #include > #include > +#include > #ifdef TRACE > #define ENTER(x) report("entering "x" \n"); > #define LEAVE(x) report("leaving "x" \n"); > @@ -70,8 +71,9 @@ > #if defined(_MSC_VER) > #define YACK() \ > { \ > - char *allocTextBuf, message[80]; \ > - unsigned long nChars; \ > + char *allocTextBuf, *message; \ > + const unsigned short longestNumber = 20; \ > + unsigned long nChars, len; \ > unsigned int errorCode = GetLastError(); \ > nChars = FormatMessage ( \ > FORMAT_MESSAGE_ALLOCATE_BUFFER | \ > @@ -82,8 +84,12 @@ > (LPSTR)&allocTextBuf, \ > 16, \ > NULL ); \ > - _snprintf_s( message, 80, 80, "Error 0x%x at %s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); \ > + len = strlen("Error 0x") + longestNumber + strlen(" at ") + strlen(__FILE__) + longestNumber + \ > + strlen(": ") + ((nChars+1) * sizeof(TCHAR)) + 1; \ > + message = malloc(len); \ > + _snprintf_s( message, len, len - 1, "Error 0x%x at %s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); \ > report_error( message ); \ > + free(message); \ > LocalFree(allocTextBuf); \ > Sleep(1); \ > } > @@ -173,7 +179,7 @@ > int serial_test( char * ); > int serial_open(const char *File, int flags, ... ); > int serial_close(int fd); > -int serial_read(int fd, void *b, int size); > +int serial_read(int fd, void *b, unsigned int size); > int serial_write(int fd, char *Str, int length); > /* > * lcc winsock.h conflicts > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx End of message. ------------------------------------------------------------------->8======= About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From bill7007 at gmail.com Mon Apr 6 16:34:50 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Mon, 6 Apr 2009 18:34:50 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: <49D693BA.8060909@gatworks.com> References: <49D546F8.20807@gatworks.com> <49D693BA.8060909@gatworks.com> Message-ID: Once it hung, three stack dumps minutes apart were exactly the same. I have a noticed that when it hangs, the read appears after flush() enter and before flush leave() that doesn't happen like: RXTXPort:SerialOutputStream:flush() enter RXTXPort:SerialInputStream:read(8192 0 8192) called When it works, flush() enter and leave happen together. It may just be because flush() hangs and read is the only other thread waiting to run at that point. I don't know much about the RXTX design and kernel interaction, just digging through the code some. Is there a design description somewhere? Am hung up on target system compile since UTS_RELEASE seems no longer defined for 2.6.18 up kernels and have not figured a good patch yet. But, that is another issue. Thanks for the good help. On Fri, Apr 3, 2009 at 6:54 PM, U. George wrote: > I would have tried 2 or 3 "^\" . If things are stuck, then all will be at > same 'java' instruction. If thread is moving, then one of the snapshots > would be different. > > I *think* flushing/draining wont return until the kernel buffers to device > have been accepted by device. Stuck/paused device? > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090406/c4b509d8/attachment-0014.html From tjarvi at qbang.org Mon Apr 6 17:45:38 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 6 Apr 2009 17:45:38 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <20090406085347.GM8289@elberon.bln.de.ingenico.com> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> <49D919A7.1070806@bbs.darktech.org> <20090406085347.GM8289@elberon.bln.de.ingenico.com> Message-ID: The error bits in the patch can probably just be dropped out. I don't see what they solve. Your snprintf define appears to work. The following is what I'd like to put in if noone objects. #if defined(_MSC_VER) # define snprintf _snprintf #endif #define YACK() \ { \ char *allocTextBuf, message[80]; \ unsigned long nChars; \ unsigned int errorCode = GetLastError(); \ nChars = FormatMessage ( \ FORMAT_MESSAGE_ALLOCATE_BUFFER | \ FORMAT_MESSAGE_FROM_SYSTEM, \ NULL, \ errorCode, \ MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT), \ (LPSTR)&allocTextBuf, \ 16, \ NULL ); \ snprintf( message, 80, "Error 0x%x at %s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); \ message[sizeof(message)-1] = '\0'; /* needed for MS CRT snprintf */ \ report_error( message ); \ LocalFree(allocTextBuf); \ Sleep(1); \ } On Mon, 6 Apr 2009, Steffen DETTMER wrote: > Hi, > > just two minor details, first about the errno change, I though > > #include > extern int errno; > > is correct (POSIX.1) - why this change? > > second about the log message, I think the maximum length could be > limited and the return value of malloc must be checked for != > NULL before using. > > Should it be > > _snprintf_s( message, 80, _TRUNCATE, "Error 0x%x at %s(%d): %s\n", > errorCode, __FILE__, __LINE__, allocTextBuf); > > (I know that MS-CRT _snprintf does not guarantee to have a final > EOS, but I think _snprintf_s with _TRUNCATE does so?). > > If it is known that truncation may happen maybe sizeof[message] > could be increased; maybe using some %.20s could be used avoiding > __FILE__ including big pathes to a message where all the message > had been cut-off. > > To have it portable I think it could be: > > /* generally: */ > #if defined(_MSC_VER) > # define snprintf _snprintf > #endif > > snprintf(message, sizeof(message), "Error 0x%x at %.20s(%d): %s\n", > errorCode, __FILE__, __LINE__, allocTextBuf); > message[sizeof(message)-1] = '\0'; /* needed for MS CRT snprintf */ > > (for length and size parameter I think size_t could be an option, > but on several platforms, including MS-CRT and older glibc, > there is no %z, unfortunately) > > oki, > > Steffen > > > * cowwoc wrote on Sun, Apr 05, 2009 at 16:50 -0400: >> >> Okay, I tracked down the crash. It's being caused by YACK() using a >> 80-character buffer. The error message is longer than 80 characters, so >> _snprintf_s() crashes to avoid a buffer overflow. >> >> Please apply the attached patch and add the zipped up Visual Studio >> project directory. It's not perfect yet but it's a good start. >> >> Gili >> >> Trent Jarvi wrote: >> > >> >CVS HEAD is currently the rxtx 2.0 code. A branch was created long >> >ago for 'experimental' gnu.io work. It just happens that the branch >> >is what everyone uses now. >> > >> >checkout -r commapi-0-0-1 rxtx-devel >> > >> >will get the branch >> > >> >On Sun, 5 Apr 2009, cowwoc wrote: >> > >> >>Trent Jarvi wrote: >> >>>It will compile with the msvc cl.exe and nmake. See Makefile.msvc >> >>>in the top level directory. You will need to adjust the JAVA_HOME >> >>>variable. Also use the MSVC command prompt for x86_64 so cl and >> >>>nmake are on your path. >> >> >> >> This is very odd. The CVS version of the code does not contain >> >>this file. Do you keep the latest code somewhere else? >> >> >> >>Gili >> >> > >> Index: ParallelImp.c >> =================================================================== >> RCS file: /usr/local/cvsroot/rxtx-devel/src/ParallelImp.c,v >> retrieving revision 1.15.2.36 >> diff -u -r1.15.2.36 ParallelImp.c >> --- ParallelImp.c 11 Feb 2009 01:04:19 -0000 1.15.2.36 >> +++ ParallelImp.c 5 Apr 2009 17:55:23 -0000 >> @@ -119,7 +119,7 @@ >> # include >> #endif >> >> -extern int errno; >> +_CRTIMP extern int * __cdecl _errno(void); >> >> #include "ParallelImp.h" >> >> @@ -181,8 +181,6 @@ >> >> #if defined (WIN32) >> >> -#define CTL_CODE( DeviceType, Function, Method, Access ) (((DeviceType) << 16) | ((Access) << 14) | ((Function) << 2) | (Method)) >> - >> #define FILE_DEVICE_PARALLEL_PORT 0x00000016 >> #define METHOD_BUFFERED 0 >> #define FILE_ANY_ACCESS 0 >> @@ -253,7 +251,6 @@ >> jobject jobj) >> { >> int fd = get_java_var( env, jobj,"fd","I" ); >> - int status; >> #if defined (__linux__) >> ioctl(fd, LPGETSTATUS, &status); >> #elif defined (WIN32) >> Index: SerialImp.c >> =================================================================== >> RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v >> retrieving revision 1.46.2.203 >> diff -u -r1.46.2.203 SerialImp.c >> --- SerialImp.c 19 Mar 2009 03:27:48 -0000 1.46.2.203 >> +++ SerialImp.c 5 Apr 2009 17:49:48 -0000 >> @@ -147,7 +147,7 @@ >> #include >> #endif /* LIBLOCKDEV */ >> >> -extern int errno; >> +_CRTIMP extern int * __cdecl _errno(void); >> >> #include "SerialImp.h" >> >> Index: termios.c >> =================================================================== >> RCS file: /usr/local/cvsroot/rxtx-devel/src/termios.c,v >> retrieving revision 1.9.2.62 >> diff -u -r1.9.2.62 termios.c >> --- termios.c 13 Jan 2009 03:08:55 -0000 1.9.2.62 >> +++ termios.c 5 Apr 2009 17:54:09 -0000 >> @@ -88,7 +88,7 @@ >> #define SIGIO 0 >> >> int my_errno; >> -extern int errno; >> +_CRTIMP extern int * __cdecl _errno(void); >> struct termios_list >> { >> char filename[80]; >> @@ -1350,7 +1350,7 @@ >> In that case use EAGAIN. See SerialImp.c:testRead() >> ----------------------------------------------------------*/ >> >> -int serial_read( int fd, void *vb, int size ) >> +int serial_read( int fd, void *vb, unsigned int size ) >> { >> long start, now; >> unsigned long nBytes = 0, total = 0, error; >> Index: win32termios.h >> =================================================================== >> RCS file: /usr/local/cvsroot/rxtx-devel/src/win32termios.h,v >> retrieving revision 1.5.2.34 >> diff -u -r1.5.2.34 win32termios.h >> --- win32termios.h 5 Feb 2009 01:25:05 -0000 1.5.2.34 >> +++ win32termios.h 5 Apr 2009 20:29:30 -0000 >> @@ -60,6 +60,7 @@ >> #include >> #include >> #include >> +#include >> #ifdef TRACE >> #define ENTER(x) report("entering "x" \n"); >> #define LEAVE(x) report("leaving "x" \n"); >> @@ -70,8 +71,9 @@ >> #if defined(_MSC_VER) >> #define YACK() \ >> { \ >> - char *allocTextBuf, message[80]; \ >> - unsigned long nChars; \ >> + char *allocTextBuf, *message; \ >> + const unsigned short longestNumber = 20; \ >> + unsigned long nChars, len; \ >> unsigned int errorCode = GetLastError(); \ >> nChars = FormatMessage ( \ >> FORMAT_MESSAGE_ALLOCATE_BUFFER | \ >> @@ -82,8 +84,12 @@ >> (LPSTR)&allocTextBuf, \ >> 16, \ >> NULL ); \ >> - _snprintf_s( message, 80, 80, "Error 0x%x at %s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); \ >> + len = strlen("Error 0x") + longestNumber + strlen(" at ") + strlen(__FILE__) + longestNumber + \ >> + strlen(": ") + ((nChars+1) * sizeof(TCHAR)) + 1; \ >> + message = malloc(len); \ >> + _snprintf_s( message, len, len - 1, "Error 0x%x at %s(%d): %s\n", errorCode, __FILE__, __LINE__, allocTextBuf); \ >> report_error( message ); \ >> + free(message); \ >> LocalFree(allocTextBuf); \ >> Sleep(1); \ >> } >> @@ -173,7 +179,7 @@ >> int serial_test( char * ); >> int serial_open(const char *File, int flags, ... ); >> int serial_close(int fd); >> -int serial_read(int fd, void *b, int size); >> +int serial_read(int fd, void *b, unsigned int size); >> int serial_write(int fd, char *Str, int length); >> /* >> * lcc winsock.h conflicts >> > > >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > > > > > > > > > > > > > > > End of message. > ------------------------------------------------------------------->8======= > > > About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. > This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > P Please consider the environment before printing this e-mail > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Apr 6 18:11:28 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 6 Apr 2009 18:11:28 -0600 (MDT) Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: <49D546F8.20807@gatworks.com> <49D693BA.8060909@gatworks.com> Message-ID: UTS_RELEASE is defined in now. The check really should be removed from RXTX. It was a defensive check for wilder times when GNU glibc did not have defines the kernel headers had so rxtx would include the kernel headers instead. :/ If you don't have linux/version.h, it is generated when you configure the kernel. make oldconfig used to do the trick. It may make sense to work with the prerelease or CVS code. RXTX just assumes that flush, read and anything else the kernel exposes may be called at anytime from any thread. There isn't a design for the kernel interaction. There are higher level constraints put in Java to prevent some things happening at the same time with 'synchronized.' RXTXPort.java has all of those. When the port is opened, a native event thread is started which uses select to know if an event has happened. BSD like systems have a native thread that fires off on write which tries to flush() to determine when the output buffer is empty asynchronously. The rest is not marshaled in any fashion at the native level. T I think there is a lower level deadlock being triggered in flush as well. I don't think it should be possible if everything was right underneath us. You may want to examine the java code closer to make sure it isnt possible the lock is there. On Mon, 6 Apr 2009, Bill Johnson wrote: > Once it hung, three stack dumps minutes apart were exactly the same. > I have a noticed that when it hangs, the read appears after flush() enter and > before flush leave() that doesn't happen like: > RXTXPort:SerialOutputStream:flush() enter > RXTXPort:SerialInputStream:read(8192 0 8192) called > > When it works, flush() enter and leave happen together. It may just be because > flush() hangs and read is the only other thread waiting to run at that point. > I don't know much about the RXTX design and kernel interaction, just digging > through the code some. Is there a design description somewhere? > > Am hung up on target system compile since UTS_RELEASE seems no longer defined for > 2.6.18 up kernels and have not figured a good patch yet. But, that is another > issue. > > Thanks for the good help. > > > On Fri, Apr 3, 2009 at 6:54 PM, U. George wrote: > I would have tried 2 or 3 "^\" . If things are stuck, then all will be > at same 'java' instruction. If thread is moving, then one of the > snapshots would be different. > > I *think* flushing/draining wont return until the kernel buffers to > device have been accepted by device. Stuck/paused device? > > > > > From tjarvi at qbang.org Mon Apr 6 18:28:50 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 6 Apr 2009 18:28:50 -0600 (MDT) Subject: [Rxtx] CVS updates. Pre3 is comming. Message-ID: I need to go through the bugzilla reports prior to the pre3 release. I think this should be close if you want to check it out from CVS. added: YACK() debug overflow fix for windows Steffen DETTMER (and many others) multiport fix for windows. Ilkka Myller http://mailman.qbang.org/pipermail/rxtx/2009-February/3989441.html I think this code is current. If I missed something, yell. CVS Info: export/setenv CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot cvs login # passwd mousy cvs checkout -r commapi-0-0-1 rxtx-devel -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Mon Apr 6 22:32:07 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 6 Apr 2009 22:32:07 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D919A7.1070806@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49D8E26B.2040705@bbs.darktech.org> <49D919A7.1070806@bbs.darktech.org> Message-ID: Ah. I'll put this in CVS tomorrow. I did sync up the code with my work sandbox today. I just forgot to pull and add this. On Sun, 5 Apr 2009, cowwoc wrote: > > Okay, I tracked down the crash. It's being caused by YACK() using a > 80-character buffer. The error message is longer than 80 characters, so > _snprintf_s() crashes to avoid a buffer overflow. > > Please apply the attached patch and add the zipped up Visual Studio > project directory. It's not perfect yet but it's a good start. > > Gili > > Trent Jarvi wrote: >> >> CVS HEAD is currently the rxtx 2.0 code. A branch was created long ago for >> 'experimental' gnu.io work. It just happens that the branch is what >> everyone uses now. >> >> checkout -r commapi-0-0-1 rxtx-devel >> >> will get the branch >> >> On Sun, 5 Apr 2009, cowwoc wrote: >> >>> Trent Jarvi wrote: >>>> It will compile with the msvc cl.exe and nmake. See Makefile.msvc in the >>>> top level directory. You will need to adjust the JAVA_HOME variable. >>>> Also use the MSVC command prompt for x86_64 so cl and nmake are on your >>>> path. >>> >>> This is very odd. The CVS version of the code does not contain this >>> file. Do you keep the latest code somewhere else? >>> >>> Gili >>> > From cowwoc at bbs.darktech.org Tue Apr 7 06:07:46 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Tue, 07 Apr 2009 08:07:46 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: References: Message-ID: <49DB4212.40807@bbs.darktech.org> > just two minor details, first about the errno change, I though > > #include > extern int errno; > > is correct (POSIX.1) - why this change? If you compile this under Visual Studio 2008 you will get warnings that the errno type being imported is different from the type being exported. The definition I pasted is the one being exported. Perhaps we should use #ifdef WIN32 for this? Gili From bill7007 at gmail.com Tue Apr 7 17:58:54 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Tue, 7 Apr 2009 19:58:54 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: <49D546F8.20807@gatworks.com> <49D693BA.8060909@gatworks.com> Message-ID: I have traced the hang down to a call to tcdrain(fd) in SerialImp.c:drain() running and rebuilt under Netbeans on the target machine with debug messages on. That puts it into the system code, so I'm not sure how to proceed. I guess I could debug into the kernel source but I've not done that. I saw some discussion about an IOCTL that sets/adjusts a timeout on tcdrain() but that may have been for BSD. Maybe there is some new setup requirement or bug introduced with this 2.6.18 kernel or a hardware difference. Below is a message listing with some of the repeated parts removed. Maybe you can see something noteworthy? JNI_OnLoad called. WARNING: RXTX Version mismatch Jar version = RXTX-2.2pre2 native lib Version = RXTX-2.2pre3 entering RXTXCommDriver:getDeviceDirectory entering RXTXPort:testRead fhs_lock: creating lockfile: 29704 fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXPort:testRead RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB2 fhs_lock: creating lockfile: 29704 fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXPort:testRead RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB1 fhs_lock: creating lockfile: 29704 fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXPort:testRead RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB0 fhs_lock: creating lockfile: 29704 fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXPort:testRead fhs_lock: creating lockfile: 29704 ... REPEATS fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXPort:testRead fhs_lock: creating lockfile: 29704 fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXCommDriver:getDeviceDirectory entering RXTXPort:testRead fhs_lock: creating lockfile: 29704 ...REPEATS fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXPort:testRead fhs_lock: creating lockfile: 29704 fhs_unlock: Removing LockFile leaving RXTXPort:testRead entering RXTXPort:Initialize RXTX WARNING: This library was compiled to run with OS release 2.6.18 and you are currently running OS release 2.6.18-92.1.6.el5. In some cases this can be a problem. Try recompiling RXTX if you notice strange behavior. If you just compiled RXTX make sure /usr/include/linux is a symbolic link to the include files that came with the kernel source and not an older copy. press enter to continue leaving RXTXPort:Initialize entering RXTXPort:open fhs_lock: creating lockfile: 29704 open: locking worked for /dev/ttyUSB2 open: fd returned is 9 leaving RXTXPort:open entering eventLoop has_line_status_register_acess: Port does not support TIOCSERGETLSR driver_has_tiocgicount: Port does not support TIOCGICOUNT events init_threads: get eis init_threads: set eis init_threads: stop leaving RXTXPort:translate_speed entering RXTXPort:nativeSetSerialPortParams entering translate_date_bits entering translate_stop_bits leaving RXTXPort:translate_stop_bits entering translate_parity leaving translate_parity entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 ...REPEATS entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 leaving RXTXPort:nativeSetSerialPortParams entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 ...REPEATS entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 entering writeArray entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 writeArray() leaving RXTXPort:writeArray entering SerialImp.c:drain() nativeDrain: trying tcdrain RXTXPort:drain() returns: 0 leaving RXTXPort:drain() entering writeArray writeArray() leaving RXTXPort:writeArray entering SerialImp.c:drain() nativeDrain: trying tcdrain entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 Tue Apr 07 18:51:49 EDT 2009:TSerial[22]:Using Port:/dev/ttyUSB2 Tue Apr 07 18:51:49 EDT 2009:TSerial[22].Transmit:TN Tue Apr 07 18:51:49 EDT 2009:TSerial[22].Transmit:RV entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 ...REPEATS FOREVER? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090407/f26e5752/attachment-0013.html From tjarvi at qbang.org Tue Apr 7 18:31:23 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 7 Apr 2009 18:31:23 -0600 (MDT) Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: <49D546F8.20807@gatworks.com> <49D693BA.8060909@gatworks.com> Message-ID: On Tue, 7 Apr 2009, Bill Johnson wrote: > I have traced the hang down to a call to tcdrain(fd) in SerialImp.c:drain() > running and rebuilt under Netbeans on the target machine with debug messages > on. That puts it into the system code, so I'm not sure how to proceed. I > guess I could debug into the kernel source but I've not done that. I saw > some discussion about an IOCTL that sets/adjusts a timeout on tcdrain() but > that may have been for BSD. Maybe there is some new setup requirement or bug > introduced with this 2.6.18 kernel or a hardware difference. > Below is a message listing with some of the repeated parts removed. Maybe > you can see something noteworthy? > > JNI_OnLoad called. > WARNING:? RXTX Version mismatch > ??????? Jar version = RXTX-2.2pre2 > ??????? native lib Version = RXTX-2.2pre3 > entering RXTXCommDriver:getDeviceDirectory > entering RXTXPort:testRead > fhs_lock: creating lockfile:????? 29704 > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXPort:testRead > RXTX Warning:? Removing stale lock file. /var/lock/LCK..ttyUSB2 > fhs_lock: creating lockfile:????? 29704 > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXPort:testRead > RXTX Warning:? Removing stale lock file. /var/lock/LCK..ttyUSB1 > fhs_lock: creating lockfile:????? 29704 > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXPort:testRead > RXTX Warning:? Removing stale lock file. /var/lock/LCK..ttyUSB0 > fhs_lock: creating lockfile:????? 29704 > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXPort:testRead > fhs_lock: creating lockfile:????? 29704 > > ... REPEATS > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXPort:testRead > fhs_lock: creating lockfile:????? 29704 > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXCommDriver:getDeviceDirectory > entering RXTXPort:testRead > fhs_lock: creating lockfile:????? 29704 > > ...REPEATS > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXPort:testRead > fhs_lock: creating lockfile:????? 29704 > > fhs_unlock: Removing LockFile > leaving RXTXPort:testRead > entering RXTXPort:Initialize > > > > RXTX WARNING:? This library was compiled to run with OS release 2.6.18 and > you are currently running OS release 2.6.18-92.1.6.el5.? In some cases this > can be a problem.? Try recompiling RXTX if you notice strange behavior.? If > you just compiled RXTX make sure /usr/include/linux is a symbolic link to > the include files that came with the kernel source and not an older copy. > > > press enter to continue > > leaving RXTXPort:Initialize > entering RXTXPort:open > fhs_lock: creating lockfile:????? 29704 > > open: locking worked for /dev/ttyUSB2 > open: fd returned is 9 > leaving RXTXPort:open > entering eventLoop > ? > has_line_status_register_acess: Port does not support TIOCSERGETLSR > ?driver_has_tiocgicount:? Port does not support TIOCGICOUNT events > init_threads: get eis > init_threads: set eis > init_threads:? stop > leaving RXTXPort:translate_speed > entering RXTXPort:nativeSetSerialPortParams > entering translate_date_bits > entering translate_stop_bits > leaving RXTXPort:translate_stop_bits > entering translate_parity > leaving translate_parity > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > ...REPEATS > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > leaving RXTXPort:nativeSetSerialPortParams > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > ...REPEATS > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > entering writeArray > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > writeArray() > leaving RXTXPort:writeArray > entering SerialImp.c:drain() > nativeDrain: trying tcdrain > RXTXPort:drain() returns: 0 > leaving RXTXPort:drain() > entering writeArray > writeArray() > leaving RXTXPort:writeArray > entering SerialImp.c:drain() > nativeDrain: trying tcdrain > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > Tue Apr 07 18:51:49 EDT 2009:TSerial[22]:Using Port:/dev/ttyUSB2 > Tue Apr 07 18:51:49 EDT 2009:TSerial[22].Transmit:TN > > Tue Apr 07 18:51:49 EDT 2009:TSerial[22].Transmit:RV > > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > ...REPEATS FOREVER? > > > Hi Bill ugh. The tiocmget... is the eventLoop checking for events. It sits with select() but has a timeout value to keep it spinning at a trivial rate. tcdrain() is the suspect. I don't see anything in the code that looks like a problem. If flow control is not enabled, I don't see a reason for it not to return. Given that this is USB, perhaps a message from the device got lost. Onboard UARTs would have a status register change when output buffer is empty. USB needs to communicate the event as an HID device which may be the source of the error. Dropping back to onboard UARTs eliminates that portion of the mix. What vendor/chipset is the USB dongle? I understand code has been pushed upon the linux serial devices for new for things like acpi. There very well could be a bug introduced. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Apr 7 18:38:22 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 7 Apr 2009 18:38:22 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49DB4212.40807@bbs.darktech.org> References: <49DB4212.40807@bbs.darktech.org> Message-ID: On Tue, 7 Apr 2009, cowwoc wrote: >> just two minor details, first about the errno change, I though >> >> #include >> extern int errno; >> >> is correct (POSIX.1) - why this change? > > If you compile this under Visual Studio 2008 you will get warnings that > the errno type being imported is different from the type being exported. > The definition I pasted is the one being exported. Perhaps we should use > #ifdef WIN32 for this? > Hi Gili, Perhaps a workaround for _MSVC is in order. GNU compilers for windows won't complain. If it's a question of MSVC or POSIX being right, the library favors the standard as a stated goal. I'm not sure what MSVC is using errno for but it should not be using it except with POSIX extensions. Perhaps #undef is enough to get rid of the warning and (maybe) has no ill consequences. Newer windows have POSIX extensions that may show how Microsoft solved the problem. It can probably fester. -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Tue Apr 7 19:54:06 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Tue, 07 Apr 2009 21:54:06 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: References: <49DB4212.40807@bbs.darktech.org> Message-ID: <49DC03BE.5010203@bbs.darktech.org> Trent Jarvi wrote: > I'm not sure what MSVC is using errno for but it should not be using it > except with POSIX extensions. Perhaps #undef is enough to get rid of > the warning and (maybe) has no ill consequences. Newer windows have > POSIX extensions that may show how Microsoft solved the problem. > > It can probably fester. What does "newer windows" refer to in this case? I was compiling using Visual Studio 2008 sp1 under Windows Vista. Both are cutting edge technologies as far as official releases go. I think you're best suited to judge whether this warning is a big deal or not so I think you should see it for yourself. Please try firing up Visual Studio 2008 (express?) against the project I sent you. Gili From Steffen.DETTMER at ingenico.com Wed Apr 8 05:50:42 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 8 Apr 2009 13:50:42 +0200 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49DC03BE.5010203@bbs.darktech.org> References: <49DB4212.40807@bbs.darktech.org> <49DC03BE.5010203@bbs.darktech.org> Message-ID: <20090408115042.GC5090@elberon.bln.de.ingenico.com> * cowwoc wrote on Tue, Apr 07, 2009 at 21:54 -0400: > Trent Jarvi wrote: > > I'm not sure what MSVC is using errno for but it should not be using it > > except with POSIX extensions. Perhaps #undef is enough to get rid of > > the warning and (maybe) has no ill consequences. Newer windows have > > POSIX extensions that may show how Microsoft solved the problem. I think here best is simply to omit this old^Wclassic `extern int errno;' line completely. I think standards just say something like `implementations may support the declaration extern int errno;'. About POSIX extensions I think in general it should be considered that althrough many things are available, even with MS Visual C++, the Microsoft tools lead developers to write non-portable code (and personally I think this is intentional). For example, they call the official ISO-C function `strerror' deprecated (!) and twaddle about some security enhancements (without even beeing specific). Someone could, because of this, lead to use the MS specific, unportable `strerror_s' instead. Even better, at _strerror_s they tell, for `ANSI compatiblity someone should use strerror_s'. Of course a program using [_]strerror_s won't be ANSI-C compliant. Do they mean strerror_r? _strerror_s has the same parameters - but of course in different order - to make porting a pain... SCNR. > What does "newer windows" refer to in this case? I was compiling using > Visual Studio 2008 sp1 under Windows Vista. Both are cutting edge > technologies as far as official releases go. `cutting edge technologies' yeah post-standard, portability-cutting technologies smoothing the way to MS world domination; own post-ANSI-C programming languages help (maybe to increase the share holder value)... SCNR. > I think you're best suited to judge whether this warning is a big deal > or not so I think you should see it for yourself. Please try firing up > Visual Studio 2008 (express?) against the project I sent you. yeah, getting the CL.EXE of 2008 running in a normal command line environment (without its special `C++ Shell') is a bit tricky - but possible. ;) oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From tjarvi at qbang.org Wed Apr 8 14:29:54 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 8 Apr 2009 14:29:54 -0600 (MDT) Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49DC03BE.5010203@bbs.darktech.org> References: <49DB4212.40807@bbs.darktech.org> <49DC03BE.5010203@bbs.darktech.org> Message-ID: The support has been around for a long time to. I don't know the details but the support appears to be tied to the OS. http://en.wikipedia.org/wiki/POSIX#POSIX_for_Windows On Tue, 7 Apr 2009, cowwoc wrote: > Trent Jarvi wrote: >> I'm not sure what MSVC is using errno for but it should not be using it >> except with POSIX extensions. Perhaps #undef is enough to get rid of the >> warning and (maybe) has no ill consequences. Newer windows have POSIX >> extensions that may show how Microsoft solved the problem. >> >> It can probably fester. > > What does "newer windows" refer to in this case? I was compiling > using Visual Studio 2008 sp1 under Windows Vista. Both are cutting edge > technologies as far as official releases go. > > I think you're best suited to judge whether this warning is a big > deal or not so I think you should see it for yourself. Please try firing up > Visual Studio 2008 (express?) against the project I sent you. > > Gili > From bill7007 at gmail.com Wed Apr 8 15:59:08 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Wed, 8 Apr 2009 17:59:08 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: <49D546F8.20807@gatworks.com> <49D693BA.8060909@gatworks.com> Message-ID: Hi Trent, I think I have hit on a work around but don't know why it works. The USB serial adapter is a "CableMAX" based on Prolific's PL2303. Backing out to the big picture, the application is old and has been very reliable until put on a new cpu and kernel. It only hangs sometimes say 25% and always at the same place, at tcdrain() on the flush() after the second write after startup. If it made it past this stage, all transmit and receive seemed reliable so it was like a startup timing issue. Since learning to debug kernel code is beyond my immediate priority, I took a shot at moving code around, adding delays, and such. I have found it good practice to do a flush after every write on streams like: outputStream.write(data.getBytes()); outputStream.flush(); If I remove the flush() after each write, the problem appears to go away! I don't think the flush is needed for a SerialOutputStream for this application anyway. Thanks for all the help, +BillJ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090408/35d96a9d/attachment-0012.html From bill7007 at gmail.com Thu Apr 9 09:20:11 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Thu, 9 Apr 2009 11:20:11 -0400 Subject: [Rxtx] Baud rate fixes in 2.2pre2 breaks 38400 on some Linux devices Message-ID: Hello, An application that worked at 38400 on a USB serial adapter (PL2303) using 2.1-7-r2 on Linux EL4 (and EL5) now fails using 2.2pre2. serialPort.setSerialPortParams(38400,SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); throws an unsupportedCommOperationException This problem matched a description of Bug 113and I posted a proposed patch there, but I don't understand the whole custom baud rate patch so it may need some thought. An older patch, [Rxtx] [Patch]: Baud Rate fixes try 1, testing encouraged., fixed some custom baud rates but apparently broke 38400 on some Linux device. Other baud rates seem to work OK. And, 38400 tested OK on local non-USB ports. My proposed patch probably breaks the custom baud rate patch since it was keyed on 38400 as a special case for Linux and my fix was to back out part of that patch, specifically: #if defined(TIOCGSERIAL) if ( cspeed == B38400 ) cspeed = 38400; #endif /* TIOCGSERIAL */ +BillJ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090409/5636af64/attachment-0011.html From cowwoc at bbs.darktech.org Fri Apr 10 08:38:49 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Fri, 10 Apr 2009 10:38:49 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: References: <49DB4212.40807@bbs.darktech.org> <49DC03BE.5010203@bbs.darktech.org> Message-ID: <49DF59F9.2050408@bbs.darktech.org> Doesn't Wikipedia list as an optional sub-system? Gili Trent Jarvi wrote: > > The support has been around for a long time to. I don't know the > details but the support appears to be tied to the OS. > > http://en.wikipedia.org/wiki/POSIX#POSIX_for_Windows > > On Tue, 7 Apr 2009, cowwoc wrote: > >> Trent Jarvi wrote: >>> I'm not sure what MSVC is using errno for but it should not be using >>> it except with POSIX extensions. Perhaps #undef is enough to get >>> rid of the warning and (maybe) has no ill consequences. Newer >>> windows have POSIX extensions that may show how Microsoft solved the >>> problem. >>> >>> It can probably fester. >> >> What does "newer windows" refer to in this case? I was compiling >> using Visual Studio 2008 sp1 under Windows Vista. Both are cutting >> edge technologies as far as official releases go. >> >> I think you're best suited to judge whether this warning is a big >> deal or not so I think you should see it for yourself. Please try >> firing up Visual Studio 2008 (express?) against the project I sent you. >> >> Gili >> From eranshuman at gmail.com Mon Apr 13 04:50:34 2009 From: eranshuman at gmail.com (Anshuman Srivastava) Date: Mon, 13 Apr 2009 16:20:34 +0530 Subject: [Rxtx] Send RTS /DTR signal Message-ID: <589913a50904130350n59cc51ffvbcd0a4eaefb4ce5f@mail.gmail.com> Hi, I want to send the RTS or DTR signal from the application Can anybody telll how to send the DTR /RTS signal using rxtxcomm libraries Thanks and regards -- Anshuman Srivastava "... in the end, it's not the years in your life that count. It's the life in your years." Buzz +91 9962515155 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090413/211b5ded/attachment-0008.html From ajmas at sympatico.ca Mon Apr 13 09:50:47 2009 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 13 Apr 2009 11:50:47 -0400 Subject: [Rxtx] Wiki Spam pages - need of captcha? Message-ID: Hi Trent, While checking for spam pages in the wiki I came across a page containing the following: "NOTICE: This page was created by a program as part of the Graffiti Network research project at Brown University. We have removed the data, but are unable to remove this page. We apologize for any inconveniences that our actions may have caused. For more information, please visit http://graffiti.cs.brown.edu/info/." Is there any chance we could add a captcha to account registration? Andr?-John From sguido at micromotive.net Mon Apr 13 09:46:15 2009 From: sguido at micromotive.net (Samuel Guido) Date: Mon, 13 Apr 2009 11:46:15 -0400 Subject: [Rxtx] Serial Output Stream Hangs on Windows Message-ID: <843C9F1C-72EE-4A40-B02A-3798EB0C57BF@micromotive.net> All, I am using RXTX in a small application to talk to a remote embedded device on a Windows host. All data is ASCII text. On physical comm ports, everything seems to be fine, messages are sent and received without much trouble. I am also trying to make the comm port selection automatic where I cycle through the available comm ports sending messages until I get the expected response. Unfortunately, when I query for the available comm ports, the bluetooth ports also show up. Whenever I try to send a string of characters to the bluetooth port, RXTX hangs way down in the call stack in the output stream, I believe in the DLL. I tried both the 2.1.7r2 and the 2.2pre2 releases and both have the same result. The send and receiving of messages from the comm port are in their own threads, but once the thread is blocked, I can't do anything with the comm ports since they are synchronized calls. The bluetooth ports are using a driver call "WIDCOMM" which I don't know who/what that is. This is on a IBM T42 laptop machine. Does anyone know what could be causing this? Is there a way to distinguish between bluetooth ports and physical comm ports? Please help, I am on a tight deadline and any help would greatly be appreciated. Thanks very much. Sam Guido From ajmas at sympatico.ca Mon Apr 13 11:04:24 2009 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 13 Apr 2009 13:04:24 -0400 Subject: [Rxtx] RxTX mentioned on Sun's Java Communications page Message-ID: Looks like RxTx gets some mention at Sun: Head over to the Java Communications page http://java.sun.com/products/javacomm/ and then click on Downloads and you get: " COMM API is a Java extension providing access to RS-232 serial ports and IEEE-1284 parallel ports (SPP mode). Sun Ray platform support is provided. Documentation and sample code are included, as well as interactive test utilities. API serial features provide access to: * Port settings (baud rate, parity, stop bits) * Port naming, mapping, enumeration (configurable) * Data transfer over TX, RX lines * DTR, CD, CTS, RTS and DSR signals * Hardware/Software flow-control * Receive-buffer threshold control * Asynchronous events indicating: * Data available on an RS-232 port * Port hardware line level changes * Port ownership changes within a JVM Update History: * javax.comm 3.0, Update 1 o Fixed problems locating and parsing portmap.conf * javax.comm 3.0, FCS o Redesigned portmapping and Sun Ray interoperability (see bundled documentation) * 2.0.3: o Added portmapping (comm.jar available 'as-is' for 3rd party native lib support)* Several Bugfixes to 2.0.3 (see bundled release notes) Note: Sun no longer offer's the Windows platform binaries of javax.comm, however javax.comm 2.0.3 can be used for the Windows platform, by using it in conjunction with the Win32 implementation layer provided by the RxTx project. To use that, download javax.comm for the 'generic' platform (which provides the front-end javax.comm API only, without platform specific back-end implementations bundled). Then acquire the Windows binary implementation rxtx-2.0.7pre1 from http://www.rxtx.org . " Looks like RxTx really is the closest thing we have to the 'official' implementation. From tjarvi at qbang.org Mon Apr 13 12:27:44 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 13 Apr 2009 12:27:44 -0600 (MDT) Subject: [Rxtx] RxTX mentioned on Sun's Java Communications page In-Reply-To: References: Message-ID: On Mon, 13 Apr 2009, Andre-John Mas wrote: > Looks like RxTx gets some mention at Sun: > > Head over to the Java Communications page http://java.sun.com/products/javacomm/ > and then click on Downloads and you get: > > " > COMM API is a Java extension providing access to RS-232 serial ports > and IEEE-1284 parallel ports (SPP mode). Sun Ray platform support is > provided. Documentation and sample code are included, as well as > interactive test utilities. API serial features provide access to: * > Port settings (baud rate, parity, stop bits) * Port naming, mapping, > enumeration (configurable) * Data transfer over TX, RX lines * DTR, > CD, CTS, RTS and DSR signals * Hardware/Software flow-control * > Receive-buffer threshold control * Asynchronous events indicating: * > Data available on an RS-232 port * Port hardware line level changes * > Port ownership changes within a JVM Update History: * javax.comm 3.0, > Update 1 o Fixed problems locating and parsing portmap.conf * > javax.comm 3.0, FCS o Redesigned portmapping and Sun Ray > interoperability (see bundled documentation) * 2.0.3: o Added > portmapping (comm.jar available 'as-is' for 3rd party native lib > support)* Several Bugfixes to 2.0.3 (see bundled release notes) Note: > Sun no longer offer's the Windows platform binaries of javax.comm, > however javax.comm 2.0.3 can be used for the Windows platform, by > using it in conjunction with the Win32 implementation layer provided > by the RxTx project. To use that, download javax.comm for the > 'generic' platform (which provides the front-end javax.comm API only, > without platform specific back-end implementations bundled). Then > acquire the Windows binary implementation rxtx-2.0.7pre1 from http://www.rxtx.org > .. > " > > Looks like RxTx really is the closest thing we have to the 'official' > implementation. Ugh. I don't know of any developer interest in maintaining rxtx 2.0. It would be cleaner for Sun to just openly take javax.comm for their Sun Ray project. If someone is interested in maintaining rxtx 2.0, don't be afraid to say so. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Mon Apr 13 16:04:19 2009 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 13 Apr 2009 17:04:19 -0500 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49D8DDEB.5010908@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> Message-ID: <49E3B6E3.5050203@cox.net> cowwoc wrote: > Trent Jarvi wrote: >> You are responsible for cleaning up the serial ports when using threads. >> That said, if the thread did shut down, finalize should have been called >> if you are not passing the object around. See RXTXPort.java. >> >> protected void finalize() >> { >> if (debug) >> z.reportln( "RXTXPort:finalize()"); >> if( fd > 0 ) >> { >> if (debug) >> z.reportln( "RXTXPort:calling close()"); >> close(); >> } >> z.finalize(); >> } > > Two points: > > 1) One should never rely on finalizers because they may never run. A PhantomRef is the way to do this kind of cleanup in most cases. It will always fire. The real issue is that you have to understand that the on the Sun JVM, the GC can run finalization or advertise a dropped reference before an object is actually unreferenced in some cases. This happens, predominately in blocks of code where object references are short lived with no class member reference that the GC can find. When the JIT compiled code just references an object on the local stack and/or a register, the GC can prematurely attempt finalization/PhantomRef notification and result in bad things happening. The single solution to this problem is to use synchronize(obj){} at the end of the block of code that obj lives in, which keeps the object from getting reclaimed prematurely. For the sake of application sanity and recovery from erroneous code, it's almost always best to put resources like this into a map, accessed by name, and make an API method that lets you find the object by name, rather than by instance reference. Then, in your code, when you want to open a serial port, you'd do something like the following, which will close anything you already opened and then open it back up. Map ports = ...; public void closePort( String port ) { CommPort p = null; p = ports.remove(port); if( p != null ) p.close(); } public CommPort public CommPort openPort( String port, String user, int timeout ) throws IOException { closePort( port ); CommPort p = CommPortIdentifier.getPortIdentifier(port). open( user, timeout ); ports.put( port, p ); return p; } Appropriate use of synchronized(ports) may be necessary if ports is not referencing a concurrency safe Map implementation such as Hashtable or ConcurrentHashMap. Gregg Wonderly From gergg at cox.net Mon Apr 13 16:36:57 2009 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 13 Apr 2009 17:36:57 -0500 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: <49D546F8.20807@gatworks.com> <49D693BA.8060909@gatworks.com> Message-ID: <49E3BE89.4020402@cox.net> Check CTS/RTS and DTR/CD etc on the device to make sure you haven't hung the kernel trying to clean up something, but it's now waiting for CTS etc. In general, you should be careful about using HW flow control when cables can be trivially unplugged or broken. Use application layer checksums or similar things to make sure data that is flowing is sane and that buffers have not overrun, resulting in lost data. Gregg Wonderly Trent Jarvi wrote: > UTS_RELEASE is defined in now. The check really should > be removed from RXTX. It was a defensive check for wilder times when GNU > glibc did not have defines the kernel headers had so rxtx would include > the kernel headers instead. :/ > > If you don't have linux/version.h, it is generated when you configure the > kernel. make oldconfig used to do the trick. It may make sense to work > with the prerelease or CVS code. > > RXTX just assumes that flush, read and anything else the kernel exposes > may be called at anytime from any thread. There isn't a design for the > kernel interaction. There are higher level constraints put in Java to > prevent some things happening at the same time with 'synchronized.' > RXTXPort.java has all of those. > > When the port is opened, a native event thread is started which uses > select to know if an event has happened. > > BSD like systems have a native thread that fires off on write which tries > to flush() to determine when the output buffer is empty asynchronously. > > The rest is not marshaled in any fashion at the native level. T > > I think there is a lower level deadlock being triggered in flush as well. > I don't think it should be possible if everything was right underneath us. > You may want to examine the java code closer to make sure it isnt possible > the lock is there. > > > On Mon, 6 Apr 2009, Bill Johnson wrote: > >> Once it hung, three stack dumps minutes apart were exactly the same. >> I have a noticed that when it hangs, the read appears after flush() enter and >> before flush leave() that doesn't happen like: >> RXTXPort:SerialOutputStream:flush() enter >> RXTXPort:SerialInputStream:read(8192 0 8192) called >> >> When it works, flush() enter and leave happen together. It may just be because >> flush() hangs and read is the only other thread waiting to run at that point. >> I don't know much about the RXTX design and kernel interaction, just digging >> through the code some. Is there a design description somewhere? >> >> Am hung up on target system compile since UTS_RELEASE seems no longer defined for >> 2.6.18 up kernels and have not figured a good patch yet. But, that is another >> issue. >> >> Thanks for the good help. >> >> >> On Fri, Apr 3, 2009 at 6:54 PM, U. George wrote: >> I would have tried 2 or 3 "^\" . If things are stuck, then all will be >> at same 'java' instruction. If thread is moving, then one of the >> snapshots would be different. >> >> I *think* flushing/draining wont return until the kernel buffers to >> device have been accepted by device. Stuck/paused device? >> >> >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From cowwoc at bbs.darktech.org Mon Apr 13 20:41:20 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Mon, 13 Apr 2009 22:41:20 -0400 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49E3B6E3.5050203@cox.net> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49E3B6E3.5050203@cox.net> Message-ID: <49E3F7D0.5090207@bbs.darktech.org> Gregg Wonderly wrote: > A PhantomRef is the way to do this kind of cleanup in most cases. It > will always fire. The real issue is that you have to understand that > the on the Sun JVM, the GC can run finalization or advertise a dropped > reference before an object is actually unreferenced in some cases. This > happens, predominately in blocks of code where object references are > short lived with no class member reference that the GC can find. When > the JIT compiled code just references an object on the local stack > and/or a register, the GC can prematurely attempt > finalization/PhantomRef notification and result in bad things happening. I've never seen this myself. Can you reproduce it on the latest JRE? If so, this sounds like a bug to me and should be fixed. Please consider filing a bug report and telling me the bug number. I'll try running it by my Sun contacts. Gili From ferry_new2004 at yahoo.com Mon Apr 13 21:24:59 2009 From: ferry_new2004 at yahoo.com (Ferry Sumendap) Date: Mon, 13 Apr 2009 20:24:59 -0700 (PDT) Subject: [Rxtx] In Linux, RXTX serial port lib cannot send character which hex is more than 127. Message-ID: <30875.39589.qm@web33106.mail.mud.yahoo.com> Hello everybody, I have just tested the RXTXserial port library version RXTX2-1-7pre20 to send two characters which are character ascii 230 and 234. It seems that the driver somehow did not send the two characters into serial port if the Operating System is Linux Mandriva 2007 (kernel version 2.6.17-13mdv ) or Linux Mandriva 2009. I also tried the driver using same java code (java class file of the program I wrote), in Windows XP, it does work. Should I configure something (special configuration in Linux) or did I miss something ? I also have tested the latest RXTX 2.2pre2 driver, but it still have that problem. Regards, Ferry -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090413/94fdfbea/attachment-0007.html From tjarvi at qbang.org Mon Apr 13 22:01:04 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 13 Apr 2009 22:01:04 -0600 (MDT) Subject: [Rxtx] In Linux, RXTX serial port lib cannot send character which hex is more than 127. In-Reply-To: <30875.39589.qm@web33106.mail.mud.yahoo.com> References: <30875.39589.qm@web33106.mail.mud.yahoo.com> Message-ID: On Mon, 13 Apr 2009, Ferry Sumendap wrote: > Hello everybody, > > I have just tested the RXTXserial port library version? RXTX2-1-7pre20 to > send two characters which are character ascii? 230 and 234. It seems that > the driver somehow did not send the two characters into serial port if the > Operating System is Linux Mandriva 2007 (kernel version 2.6.17-13mdv > ) or Linux Mandriva 2009. > I also tried the driver using? same java code (java class file of the > program I wrote), in Windows XP,? it does work. > > Should I configure something (special configuration in Linux)? or did I miss > something ? > I also have tested the latest RXTX 2.2pre2 driver, but it still have that > problem. > Hello Ferry This sounds like an unlikely problem. Even with USB dongle issues, I can't think of a reason that would be a problem. Is this a connection at 9600 8N1? Sometimes it really is the cable. -- Trent Jarvi tjarvi at qbang.org From ferry_new2004 at yahoo.com Mon Apr 13 22:15:04 2009 From: ferry_new2004 at yahoo.com (Ferry Sumendap) Date: Mon, 13 Apr 2009 21:15:04 -0700 (PDT) Subject: [Rxtx] Fw: In Linux, RXTX serial port lib cannot send character which hex is more than 127. Message-ID: <948418.50805.qm@web33103.mail.mud.yahoo.com> ----- Forwarded Message ---- From: Ferry Sumendap To: Trent Jarvi Sent: Tuesday, April 14, 2009 11:10:04 AM Subject: Re: [Rxtx] In Linux, RXTX serial port lib cannot send character which hex is more than 127. Thank you for your answer. I use the same machine, cable and devices to test. My PC is installed with Linux Mandriva and WINDOWS. The serial port physically have no problem since using Windows, it works. I also tested the serial port using MONI (tcl based program). MONI is linux based program to send some characters to serial port. Using MONI, I sent the characters to /dev/ttyS0, and it works because the device which is plugged in /dev/ttyS0 received and answered the message. But for RXTX, some how, java based program cannot send those characters. With the same java based program, it works properly in WINDOWS and the same cable, devices, hardware specification. That's why I am curious about RXTX. Here is the serial port configuration I used. Com Port /dev/ttyS0 Baud rate 19200 Data bits 8 ( value = 8) Stop bits 1 ( value = 1) Parity None ( value = 0) Thank you very much for your response. Regards, Ferry ________________________________ From: Trent Jarvi To: Ferry Sumendap Cc: rxtx at qbang.org Sent: Tuesday, April 14, 2009 11:01:04 AM Subject: Re: [Rxtx] In Linux, RXTX serial port lib cannot send character which hex is more than 127. On Mon, 13 Apr 2009, Ferry Sumendap wrote: > Hello everybody, > > I have just tested the RXTXserial port library version RXTX2-1-7pre20 to > send two characters which are character ascii 230 and 234. It seems that > the driver somehow did not send the two characters into serial port if the > Operating System is Linux Mandriva 2007 (kernel version 2.6.17-13mdv > ) or Linux Mandriva 2009. > I also tried the driver using same java code (java class file of the > program I wrote), in Windows XP, it does work. > > Should I configure something (special configuration in Linux) or did I miss > something ? > I also have tested the latest RXTX 2.2pre2 driver, but it still have that > problem. > Hello Ferry This sounds like an unlikely problem. Even with USB dongle issues, I can't think of a reason that would be a problem. Is this a connection at 9600 8N1? Sometimes it really is the cable. -- Trent Jarvi tjarvi at qbang.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090413/27a37ea5/attachment-0007.html From ferry_new2004 at yahoo.com Mon Apr 13 22:23:53 2009 From: ferry_new2004 at yahoo.com (Ferry Sumendap) Date: Mon, 13 Apr 2009 21:23:53 -0700 (PDT) Subject: [Rxtx] In Linux, RXTX serial port lib cannot send character which hex is more than 127. In-Reply-To: References: <30875.39589.qm@web33106.mail.mud.yahoo.com> <81465.86461.qm@web33102.mail.mud.yahoo.com> Message-ID: <736778.48214.qm@web33108.mail.mud.yahoo.com> I am sorry not telling you about the configuration.. Yes I did test using the same serial port configuration, but the RXTX did not work properly. I also use "root" just in case there is security violation. If I sent another character that is below 127 (ascii < 127) the RXTX works properly either in LINUX or WINDOWS. I also cannot believe that coders of RXTX would make diffentiation between baudrate 19200 and 9600. The driver actually works very good unfortunately if the character is upper than ascii 127 (like ascii 230 and 234) it will not work. Thank you very much. Regards, Ferry ________________________________ From: Trent Jarvi To: Ferry Sumendap Cc: Trent Jarvi Sent: Tuesday, April 14, 2009 11:16:34 AM Subject: Re: [Rxtx] In Linux, RXTX serial port lib cannot send character which hex is more than 127. Hi Ferry, The only thing you mention that is not tested on a regular basis is the 19200 baudrate. There is nothing special (code wise) about that baudrate. On Mon, 13 Apr 2009, Ferry Sumendap wrote: > Thank you for your answer. > > I use the same machine, cable and devices to test. > My PC is installed with Linux Mandriva and WINDOWS. > The serial port physically have no problem since using Windows, it works. > > I also tested the serial port using MONI (tcl based program). > MONI is linux based program to send some characters to serial port. > Using MONI, I sent the characters to /dev/ttyS0, and it works because the > device which is plugged in /dev/ttyS0 received and answered the message. > > But for RXTX, some how, java based program cannot send those characters. > With the same java based program, it works properly in WINDOWS and the same > cable, devices, hardware specification. > That's why I am curious about RXTX. > > > > Here is the serial port configuration I used. > > Com Port /dev/ttyS0 > Baud rate 19200 > Data bits 8 ( value = 8) > Stop bits 1 ( value = 1) > Parity None ( value = 0) > > > > Thank you very much for your response. > > Regards, > Ferry > > > ____________________________________________________________________________ > From: Trent Jarvi > To: Ferry Sumendap > Cc: rxtx at qbang.org > Sent: Tuesday, April 14, 2009 11:01:04 AM > Subject: Re: [Rxtx] In Linux, RXTX serial port lib cannot send character > which hex is more than 127. > > > > On Mon, 13 Apr 2009, Ferry Sumendap wrote: > > > Hello everybody, > > > > I have just tested the RXTXserial port library version RXTX2-1-7pre20 to > > send two characters which are character ascii 230 and 234. It seems that > > the driver somehow did not send the two characters into serial port if the > > Operating System is Linux Mandriva 2007 (kernel version 2.6.17-13mdv > > ) or Linux Mandriva 2009. > > I also tried the driver using same java code (java class file of the > > program I wrote), in Windows XP, it does work. > > > > Should I configure something (special configuration in Linux) or did I > miss > > something ? > > I also have tested the latest RXTX 2.2pre2 driver, but it still have that > > problem. > > > > Hello Ferry > > This sounds like an unlikely problem. > > Even with USB dongle issues, I can't think of a reason that would be a > problem. Is this a connection at 9600 8N1? > > Sometimes it really is the cable. > > -- > Trent Jarvi > tjarvi at qbang.org > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090413/7a2fd5a0/attachment-0007.html From tjarvi at qbang.org Mon Apr 13 22:45:09 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 13 Apr 2009 22:45:09 -0600 (MDT) Subject: [Rxtx] In Linux, RXTX serial port lib cannot send character which hex is more than 127. In-Reply-To: <736778.48214.qm@web33108.mail.mud.yahoo.com> References: <30875.39589.qm@web33106.mail.mud.yahoo.com> <81465.86461.qm@web33102.mail.mud.yahoo.com> <736778.48214.qm@web33108.mail.mud.yahoo.com> Message-ID: This sounds like a signed vs unsigned char issue. Given that rxtx does binary read and write fine on Linux, I'm at a loss of what your problem may be. No, I don't suspect the baudrate is an issue either. On Mon, 13 Apr 2009, Ferry Sumendap wrote: > I am sorry not telling you about the configuration.. > > Yes I did test using the same serial port configuration, but the RXTX did > not work properly. > I also use "root" just in case there is security violation. > If? I sent another character that is below 127 (ascii < 127) the RXTX works > properly either in LINUX or WINDOWS. > > I also cannot believe that coders of RXTX would make diffentiation between > baudrate 19200 and 9600. > The driver actually works very good unfortunately if the character is upper > than ascii 127 (like ascii 230 and 234) it will not work. > > Thank you very much. > Regards, > > Ferry > > ____________________________________________________________________________ > From: Trent Jarvi > To: Ferry Sumendap > Cc: Trent Jarvi > Sent: Tuesday, April 14, 2009 11:16:34 AM > Subject: Re: [Rxtx] In Linux, RXTX serial port lib cannot send character > which hex is more than 127. > > > Hi Ferry, > > The only thing you mention that is not tested on a regular basis is the > 19200 baudrate.? There is nothing special (code wise) about that baudrate. > > On Mon, 13 Apr 2009, Ferry Sumendap wrote: > > > Thank you for your answer. > > > > I use the same machine, cable and devices to test. > > My PC is installed with Linux Mandriva and WINDOWS. > > The serial port physically have no problem since using Windows, it works. > > > > I also tested the serial port using MONI (tcl based program). > > MONI is linux based program to send some characters to serial port. > > Using MONI, I sent the characters to /dev/ttyS0, and it works because the > > device which is plugged in /dev/ttyS0 received and answered the message. > > > > But for RXTX, some how, java based program cannot send those characters. > > With the same java based program, it works properly in WINDOWS and the > same > > cable, devices, hardware specification. > > That's why I am curious about RXTX. > > > > > > > > Here is the serial port configuration I used. > > > > Com Port /dev/ttyS0 > > Baud rate 19200 > > Data bits 8 ( value = 8) > > Stop bits 1?? ( value = 1) > > Parity None? ( value = 0) > > > > > > > > Thank you very much for your response. > > > > Regards, > > Ferry > > > > > >___________________________________________________________________________ > _ > > From: Trent Jarvi > > To: Ferry Sumendap > > Cc: rxtx at qbang.org > > Sent: Tuesday, April 14, 2009 11:01:04 AM > > Subject: Re: [Rxtx] In Linux, RXTX serial port lib cannot send character > > which hex is more than 127. > > > > > > > > On Mon, 13 Apr 2009, Ferry Sumendap wrote: > > > > > Hello everybody, > > > > > > I have just tested the RXTXserial port library version? RXTX2-1-7pre20 > to > > > send two characters which are character ascii? 230 and 234. It seems > that > > > the driver somehow did not send the two characters into serial port if > the > > > Operating System is Linux Mandriva 2007 (kernel version 2.6.17-13mdv > > > ) or Linux Mandriva 2009. > > > I also tried the driver using? same java code (java class file of the > > > program I wrote), in Windows XP,? it does work. > > > > > > Should I configure something (special configuration in Linux)? or did I > > miss > > > something ? > > > I also have tested the latest RXTX 2.2pre2 driver, but it still have > that > > > problem. > > > > > > > Hello Ferry > > > > This sounds like an unlikely problem. > > > > Even with USB dongle issues, I can't think of a reason that would be a > > problem.? Is this a connection at 9600 8N1? > > > > Sometimes it really is the cable. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > > > > > > > > From ilkka at myller.com Mon Apr 13 23:12:16 2009 From: ilkka at myller.com (Ilkka Myller) Date: Tue, 14 Apr 2009 08:12:16 +0300 Subject: [Rxtx] In Linux, RXTX serial port lib cannot send character which hex is more than 127. In-Reply-To: References: <30875.39589.qm@web33106.mail.mud.yahoo.com> <81465.86461.qm@web33102.mail.mud.yahoo.com> <736778.48214.qm@web33108.mail.mud.yahoo.com> Message-ID: Hi, Another suggestion: incorrect java byte casting. Java byte type has a range from -128 to 127. I've seen people assume range of 0 - 255. Incorrect integer casting with bytes is a common mistake is to cause those >127 ascii issues. Could it be? (int)b versus (int)(b & 0xFF) -- I Trent Jarvi kirjoitti 14.4.2009 kello 7.45: > > This sounds like a signed vs unsigned char issue. Given that rxtx > does binary read and write fine on Linux, I'm at a loss of what your > problem may be. > > No, I don't suspect the baudrate is an issue either. > > On Mon, 13 Apr 2009, Ferry Sumendap wrote: > >> I am sorry not telling you about the configuration.. >> Yes I did test using the same serial port configuration, but the >> RXTX did >> not work properly. >> I also use "root" just in case there is security violation. >> If I sent another character that is below 127 (ascii < 127) the >> RXTX works >> properly either in LINUX or WINDOWS. >> I also cannot believe that coders of RXTX would make diffentiation >> between >> baudrate 19200 and 9600. >> The driver actually works very good unfortunately if the character >> is upper >> than ascii 127 (like ascii 230 and 234) it will not work. >> Thank you very much. >> Regards, >> Ferry >> ____________________________________________________________________________ >> From: Trent Jarvi >> To: Ferry Sumendap >> Cc: Trent Jarvi >> Sent: Tuesday, April 14, 2009 11:16:34 AM >> Subject: Re: [Rxtx] In Linux, RXTX serial port lib cannot send >> character >> which hex is more than 127. >> Hi Ferry, >> The only thing you mention that is not tested on a regular basis is >> the >> 19200 baudrate. There is nothing special (code wise) about that >> baudrate. >> On Mon, 13 Apr 2009, Ferry Sumendap wrote: >> > Thank you for your answer. >> > >> > I use the same machine, cable and devices to test. >> > My PC is installed with Linux Mandriva and WINDOWS. >> > The serial port physically have no problem since using Windows, >> it works. >> > >> > I also tested the serial port using MONI (tcl based program). >> > MONI is linux based program to send some characters to serial port. >> > Using MONI, I sent the characters to /dev/ttyS0, and it works >> because the >> > device which is plugged in /dev/ttyS0 received and answered the >> message. >> > >> > But for RXTX, some how, java based program cannot send those >> characters. >> > With the same java based program, it works properly in WINDOWS >> and the >> same >> > cable, devices, hardware specification. >> > That's why I am curious about RXTX. >> > >> > >> > >> > Here is the serial port configuration I used. >> > >> > Com Port /dev/ttyS0 >> > Baud rate 19200 >> > Data bits 8 ( value = 8) >> > Stop bits 1 ( value = 1) >> > Parity None ( value = 0) >> > >> > >> > >> > Thank you very much for your response. >> > >> > Regards, >> > Ferry >> > >> > >> > >> ___________________________________________________________________________ >> _ >> > From: Trent Jarvi >> > To: Ferry Sumendap >> > Cc: rxtx at qbang.org >> > Sent: Tuesday, April 14, 2009 11:01:04 AM >> > Subject: Re: [Rxtx] In Linux, RXTX serial port lib cannot send >> character >> > which hex is more than 127. >> > >> > >> > >> > On Mon, 13 Apr 2009, Ferry Sumendap wrote: >> > >> > > Hello everybody, >> > > >> > > I have just tested the RXTXserial port library version >> RXTX2-1-7pre20 >> to >> > > send two characters which are character ascii 230 and 234. It >> seems >> that >> > > the driver somehow did not send the two characters into serial >> port if >> the >> > > Operating System is Linux Mandriva 2007 (kernel version >> 2.6.17-13mdv >> > > ) or Linux Mandriva 2009. >> > > I also tried the driver using same java code (java class file >> of the >> > > program I wrote), in Windows XP, it does work. >> > > >> > > Should I configure something (special configuration in Linux) >> or did I >> > miss >> > > something ? >> > > I also have tested the latest RXTX 2.2pre2 driver, but it still >> have >> that >> > > problem. >> > > >> > >> > Hello Ferry >> > >> > This sounds like an unlikely problem. >> > >> > Even with USB dongle issues, I can't think of a reason that would >> be a >> > problem. Is this a connection at 9600 8N1? >> > >> > Sometimes it really is the cable. >> > >> > -- >> > Trent Jarvi >> > tjarvi at qbang.org >> > >> > >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From sunil at saltriver.com Tue Apr 14 01:06:38 2009 From: sunil at saltriver.com (Sunil Bhambani) Date: Tue, 14 Apr 2009 07:06:38 -0000 Subject: [Rxtx] RxTx on Mac for USB Message-ID: <1080422816.3127.6.camel@localhost.localdomain> Hi, I have a GPS device which is USB device. I want to use that device on Mac System and Java as the programming language. I have read that USB support through RxTx on Mac is not there. Is this correct? I would like to read the data that comes to GPS device. Can some connector be used to communicate with that device. For example USB to RJ11 or USB to serial connector? Are this connectors reliable enough to be used? Hope to get the reply soon. -- Thank & Regards Sunil -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090414/295ccb1d/attachment-0006.html From helgeingvart at gmail.com Tue Apr 14 01:43:04 2009 From: helgeingvart at gmail.com (Helge Fredriksen) Date: Tue, 14 Apr 2009 09:43:04 +0200 Subject: [Rxtx] IO exceptions on 2.2pre2 In-Reply-To: References: <306B677E-9207-44CB-81CD-787A50DB7DA6@myller.com> Message-ID: FYI: There seem to be success on this problem by switching to your commercial counterpart from SerialIO (http://www.serialio.com). A FTDI only problem? Best regards, Helge Fredriksen On Sat, Mar 28, 2009 at 5:32 PM, Helge Fredriksen wrote: > Thanks for your suggestions, > > We have tried switching off the power saving settings as recommended, but > regrettably we see the same things happening still. > > The FTDI device is not connected directly to USB hubs, no. > > Someone have any more ideas? > > Best regards, > Helge Fredriksen > > > On Tue, Mar 24, 2009 at 9:27 AM, Ilkka Myller wrote: > >> Hi Helge, >> >> I am not sure if this will help, but you could try this: >> >> echo on > /sys/bus/usb/devices//power/level >> echo 0 > /sys/bus/usb/devices//power/autosuspend >> >> is the USB-bus device id of your FTDI adapter (bus-device, for >> example "2-2") >> >> This will disable USB power saving/autosuspend of FTDI USB-device. >> I've seen some some systems where this helps with FTDI-adapter connection >> drops. >> >> Also: is your FTDI device directly connected to PC's USB root hub? If not, >> test that too. >> >> >> -- >> I >> >> (replace with the usb bus device id of your FTDI serial >> adapter) >> >> Helge Fredriksen kirjoitti 24.3.2009 kello 9.45: >> >> Hello! >> >> Here's the device details: >> >> FT232R is a USB to serial UART interface. >> >> Link to componentt: http://www.ftdichip.com/Products/FT232R.htm >> >> Regards, >> Helge Fredriksen >> >> On Tue, Mar 24, 2009 at 12:05 AM, Trent Jarvi wrote: >> >>> >>> >>> On Mon, 23 Mar 2009, Helge Fredriksen wrote: >>> >>> Hello again. >>>> >>>> I'm having a bit trouble with the 2.2pre2 version it seems. I'm having >>>> an >>>> application running on Ubuntu 8.10 that seem to run stable but after an >>>> hour >>>> or so the application breaks down with lot's of IO exceptions like this: >>>> >>>> java.io.IOException: Input/output error in nativeavailable >>>> at gnu.io.RXTXPort.nativeavailable(Native Method) >>>> at gnu.io.RXTXPort$SerialInputStream.available(RXTXPort.java:1596) >>>> >>>> atcom.poseidon.usb.UsbInterface$MySerialPortEventListener.serialEvent(UsbInte >>>> rface.java:251) >>>> at gnu.io.RXTXPort.sendEvent(RXTXPort.java:772) >>>> at gnu.io.RXTXPort.eventLoop(Native Method) >>>> at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1641) >>>> >>>> Any ideas? >>>> >>> >>> Hi Helge, >>> >>> It sounds like the file descriptor (USB driver) is in an invalid state. >>> >>> What can you tell us about the USB dongle? Is it bluetooth? Do you know >>> what chipset is in it? >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090414/e2c97c4f/attachment-0007.html From Steffen.DETTMER at ingenico.com Tue Apr 14 02:21:35 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 14 Apr 2009 10:21:35 +0200 Subject: [Rxtx] Crash in termios.c:892 In-Reply-To: <49E3F7D0.5090207@bbs.darktech.org> References: <49D8413D.7040105@bbs.darktech.org> <49D8DDEB.5010908@bbs.darktech.org> <49E3B6E3.5050203@cox.net> <49E3F7D0.5090207@bbs.darktech.org> Message-ID: <20090414082135.GG5090@elberon.bln.de.ingenico.com> * cowwoc wrote on Mon, Apr 13, 2009 at 22:41 -0400: > Gregg Wonderly wrote: > > The real issue is that you have to understand that > > the on the Sun JVM, the GC can run finalization or advertise a dropped > > reference before an object is actually unreferenced in some cases. > > I've never seen this myself. Can you reproduce it on the latest JRE? If > so, this sounds like a bug to me and should be fixed. Please consider > filing a bug report and telling me the bug number. I'll try running it > by my Sun contacts. I found some general hints here: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2261.html Traditional finalization in garbage collected languages is defined in terms of object reachability. But objects can easily become "unreachable" earlier than the programmer expects, due to compiler optimizations. An object may be logically in use long past the last point at which the memory associated with the object is accessed or referenced by any pointers visible to the garbage collector. In the worst case, the compiler might decide to store all the fields of an object in registers, and then observe that the "this" pointer for the newly allocated memory is dead immediately after the allocation, and hence not save it anywhere. The garbage collector, even if run immediately after the allocation, would then discover that the memory object is no longer reachable, and run the finalizer immediately, in spite of the fact that the object fields are still in use, and in fact may remain in use after the finalizer has run. However, if this would be a so general weakness that someone is adviced to store object instances in collections instead of using members or having the references on the stack - even if used correctly - I think it would be a major weakness which probably had been fixed, because otherwise raping collections as such workarounds would be commonly visible. BTW, I think the citation above is wrong if the optimised member values are used after that. The destructor / finalizer may set all fields to null or so and (ordinary) optimizers should not affect the behavior of correct and usual code I think. (ohh, and Cowwoc, forced-GC and to forbid the developer to control lifecycle in Java is considered a feature, not a bug! -- SCNR) oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From michael.erskine at ketech.com Tue Apr 14 02:50:53 2009 From: michael.erskine at ketech.com (Michael Erskine) Date: Tue, 14 Apr 2009 09:50:53 +0100 Subject: [Rxtx] Wiki Spam pages - need of captcha? In-Reply-To: References: Message-ID: <06BA3262D918014F9183B66425D5A8D45FA42D88FB@no-sv-03.ketech.local> All, See http://tech.slashdot.org/article.pl?sid=09/04/13/0120226 for details of this particular use of open wiki sites and the apology. Regards, Michael Erskine. From Steffen.DETTMER at ingenico.com Tue Apr 14 04:27:53 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 14 Apr 2009 12:27:53 +0200 Subject: [Rxtx] In Linux, RXTX serial port lib cannot send character which hex is more than 127. In-Reply-To: <30875.39589.qm@web33106.mail.mud.yahoo.com> References: <30875.39589.qm@web33106.mail.mud.yahoo.com> Message-ID: <20090414102753.GI5090@elberon.bln.de.ingenico.com> * Ferry Sumendap wrote on Mon, Apr 13, 2009 at 20:24 -0700: > I have just tested the RXTXserial port library version > RXTX2-1-7pre20 to send two characters which are character ascii > 230 and 234. Can you send -26 and -22 instead? Then it probably is a casting issue (as Trent and Ilkka already considered). oki, Steffen End of message. ------------------------------------------------------------------->8======= About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Bob_Jacobsen at lbl.gov Tue Apr 14 08:31:13 2009 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Tue, 14 Apr 2009 07:31:13 -0700 Subject: [Rxtx] RxTx on Mac for USB In-Reply-To: <1080422816.3127.6.camel@localhost.localdomain> References: <1080422816.3127.6.camel@localhost.localdomain> Message-ID: At 2:56 AM +0530 3/28/04, Sunil Bhambani wrote: >Hi, > >I have a GPS device which is USB device. I want to use that device >on Mac System and Java as the programming language. I have read that >USB support through RxTx on Mac is not there. Is this correct? I >would like to read the data that comes to GPS device. Can some >connector be used to communicate with that device. For example USB >to RJ11 or USB to serial connector? Are this connectors reliable >enough to be used? If the GPS device looks like a serial device to Mac OS X (Darwin), RXTX will work fine. To check: *) Unplug your device. *) Do the following command line, and keep the output: ls -lt /dev/ | head -10 *) Plug in your device and wait a couple seconds *) Repeat the above command line, and see if there are any new entries at the top of the output. The new entries, if any, are how your GPS device was mounted. If the new device(s) start with /dev/tty or /dev/cu, you'll be able to use RXTX. As a next step, you can use the "cu" command to try to talk to your GPS device as serial device. For example, cu -s 19200 -l /dev/tty.usbserial-LWPMMU13 You can download RXTX installers for various MacOS X version from here: But note these are for RXTX 2.0 versions (javax.comm package). Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From sunil at saltriver.com Wed Apr 15 00:06:40 2009 From: sunil at saltriver.com (Sunil Bhambani) Date: Wed, 15 Apr 2009 06:06:40 -0000 Subject: [Rxtx] RxTx on Mac for USB In-Reply-To: References: <1080422816.3127.6.camel@localhost.localdomain> Message-ID: <1080505612.2924.9.camel@localhost.localdomain> On Tue, 2009-04-14 at 07:31 -0700, Bob Jacobsen wrote: > At 2:56 AM +0530 3/28/04, Sunil Bhambani wrote: > >Hi, > > > >I have a GPS device which is USB device. I want to use that device > >on Mac System and Java as the programming language. I have read that > >USB support through RxTx on Mac is not there. Is this correct? I > >would like to read the data that comes to GPS device. Can some > >connector be used to communicate with that device. For example USB > >to RJ11 or USB to serial connector? Are this connectors reliable > >enough to be used? > > If the GPS device looks like a serial device to Mac OS X (Darwin), > RXTX will work fine. > > To check: > > *) Unplug your device. > *) Do the following command line, and keep the output: > > ls -lt /dev/ | head -10 > > *) Plug in your device and wait a couple seconds > > *) Repeat the above command line, and see if there are any new > entries at the top of the output. > > The new entries, if any, are how your GPS device was mounted. If the > new device(s) start with /dev/tty or /dev/cu, you'll be able to use > RXTX. > > As a next step, you can use the "cu" command to try to talk to your > GPS device as serial device. For example, > > cu -s 19200 -l /dev/tty.usbserial-LWPMMU13 > > You can download RXTX installers for various MacOS X version from here: > > > > But note these are for RXTX 2.0 versions (javax.comm package). > > Bob Hi Bob, I am using Mac 10.5 and I have done what you have said. I get the following output total 4 crw--w---- 1 Saltriver tty 16, 0 Apr 15 11:13 ttys000 crw-rw-rw- 1 root wheel 8, 0 Apr 15 11:13 random crw-rw-rw- 1 root tty 15, 1 Apr 15 11:13 ptmx crw------- 1 Saltriver staff 0, 0 Apr 15 11:10 console crw-rw-rw- 1 root wheel 3, 2 Apr 15 10:58 null crw------- 1 root wheel 23, 1 Apr 15 10:32 bpf1 crw------- 1 root wheel 23, 0 Apr 15 10:32 bpf0 crw------- 1 root wheel 11, 0 Apr 15 10:31 autofs crw------- 1 root wheel 17, 0 Apr 15 10:31 autofs_control saltriver-infosystemss-mac-mini:~ Saltriver$ ls -lt /dev/ | head -10 total 4 crw--w---- 1 Saltriver tty 16, 0 Apr 15 11:16 ttys000 crw-rw-rw- 1 root tty 15, 1 Apr 15 11:16 ptmx crw-rw-rw- 1 root wheel 8, 0 Apr 15 11:13 random crw------- 1 Saltriver staff 0, 0 Apr 15 11:10 console crw-rw-rw- 1 root wheel 3, 2 Apr 15 10:58 null crw------- 1 root wheel 23, 1 Apr 15 10:32 bpf1 crw------- 1 root wheel 23, 0 Apr 15 10:32 bpf0 crw------- 1 root wheel 11, 0 Apr 15 10:31 autofs crw------- 1 root wheel 17, 0 Apr 15 10:31 autofs_control I think the output is same in both. Is there any way of mounting that device. I am very new to Mac. I am using RXTX 2.1 without javax.comm package. I have tried the same code in fedora and it ran successfully. I have tried inserting pen drive in the USB port and it was detected. Hope to get a quick reply from you. Thanks & Regards Sunil -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090415/19e599e5/attachment-0005.html From Bob_Jacobsen at lbl.gov Wed Apr 15 03:43:26 2009 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Wed, 15 Apr 2009 02:43:26 -0700 Subject: [Rxtx] RxTx on Mac for USB In-Reply-To: <1080505612.2924.9.camel@localhost.localdomain> References: <1080422816.3127.6.camel@localhost.localdomain> <1080505612.2924.9.camel@localhost.localdomain> Message-ID: At 1:56 AM +0530 3/29/04, Sunil Bhambani wrote: > >I am using Mac 10.5 and I have done what you have said. I get the >following output > >total 4 >crw--w---- 1 Saltriver tty 16, 0 Apr 15 11:13 ttys000 >crw-rw-rw- 1 root wheel 8, 0 Apr 15 11:13 random >crw-rw-rw- 1 root tty 15, 1 Apr 15 11:13 ptmx >crw------- 1 Saltriver staff 0, 0 Apr 15 11:10 console ... >saltriver-infosystemss-mac-mini:~ Saltriver$ ls -lt /dev/ | head -10 >total 4 >crw--w---- 1 Saltriver tty 16, 0 Apr 15 11:16 ttys000 >crw-rw-rw- 1 root tty 15, 1 Apr 15 11:16 ptmx >crw-rw-rw- 1 root wheel 8, 0 Apr 15 11:13 random >crw------- 1 Saltriver staff 0, 0 Apr 15 11:10 console ... >I think the output is same in both. Is there any way of mounting that device. You're going to need a driver of some sort that will make the GPS unit appear as a serial device. > I am very new to Mac. I am using RXTX 2.1 without javax.comm package. This problem is happening before RXTX can do anything at all. Unless there's a device in /dev, RXTX can't even begin to be involved. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From cowwoc at bbs.darktech.org Wed Apr 15 09:08:21 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Wed, 15 Apr 2009 11:08:21 -0400 Subject: [Rxtx] RxTX mentioned on Sun's Java Communications page In-Reply-To: References: Message-ID: <49E5F865.1030206@bbs.darktech.org> >> Looks like RxTx really is the closest thing we have to the 'official' >> implementation. > > Ugh. I don't know of any developer interest in maintaining rxtx 2.0. It > would be cleaner for Sun to just openly take javax.comm for their Sun Ray > project. > > If someone is interested in maintaining rxtx 2.0, don't be afraid to say > so. Just curious, why not have the javax.comm layer just call gnu.io under the hood? This will make require no real work to maintain it even if the underlying implementation keeps on changing. From what I've seen so far the difference between the two APIs is minimal in most places. Gili From Kustaa.Nyholm at planmeca.com Wed Apr 15 09:42:33 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 15 Apr 2009 18:42:33 +0300 Subject: [Rxtx] Java5 support In-Reply-To: <49D7CD82.1040904@bbs.darktech.org> Message-ID: A recent post reminded me of this old thread that I do not think got any replies. Here is my take on the subject (of improving the API): Please do not 'improve' the API! Serial port is an old, simple and mature thing. Let's keep it that way. Very little will be gained by 'improving' it. It is already too bad that Sun spoiled the internals of javax.comm in version 3,0 so that the gnu.io package had to be coined. That is a nuisance but nothing compared to what happens if we start 'improve' the API and make it incompatible with Java Comm API. Even additions should be resisted as this will encourage people to write code that is not compatible with the 'standard' Java Comm API. The world does not need more standards but better compliance to existing standards. If someone feels things like generics/iterators for are needed it is simple to wrap the rxtx or java comm classes into classes to implement these new language features without changing the API. rxtx us great and many thanks and cudos to the maintainers and creators but it is lamentable that something this basic needs to be addressed outside standard JRE. Not to mention being able to do basic USB stuff in Java/std JRE in cross platform deployable fashion. br Kusti > From: cowwoc > Date: Sun, 5 Apr 2009 00:13:38 +0300 > To: > Conversation: [Rxtx] Java5 support > Subject: [Rxtx] Java5 support > > > > Now that you dropped javax.comm support, how about improving the API > by replacing Enumation by Iterator, int by enum, and using Generics? It > would improve the usability of the API. > > Gili > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From cowwoc at bbs.darktech.org Wed Apr 15 11:35:03 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Wed, 15 Apr 2009 13:35:03 -0400 Subject: [Rxtx] YACK Message-ID: <49E61AC7.2060701@bbs.darktech.org> Hi, Please increase the YACK() buffer size from 80 characters to 160. My long paths lead to the following kinds of errors: Error 0x5 at c:\users\gili\documents\rxtx\rxtx-devel\src\termios.c(892): AccessError 0x5 at c:\users\gili\documents\rxtx\rxtx-devel\src\termios.c(892): Access Thanks, Gili From talberts at msiscales.com Wed Apr 15 12:22:20 2009 From: talberts at msiscales.com (Tim Alberts) Date: Wed, 15 Apr 2009 11:22:20 -0700 Subject: [Rxtx] RxTX mentioned on Sun's Java Communications page In-Reply-To: <49E5F865.1030206@bbs.darktech.org> References: <49E5F865.1030206@bbs.darktech.org> Message-ID: <49E625DC.80509@msiscales.com> cowwoc wrote: >>> Looks like RxTx really is the closest thing we have to the 'official' >>> implementation. >>> >> Ugh. I don't know of any developer interest in maintaining rxtx 2.0. It >> would be cleaner for Sun to just openly take javax.comm for their Sun Ray >> project. >> >> If someone is interested in maintaining rxtx 2.0, don't be afraid to say >> so. >> > > Just curious, why not have the javax.comm layer just call gnu.io under > the hood? This will make require no real work to maintain it even if the > underlying implementation keeps on changing. From what I've seen so far > the difference between the two APIs is minimal in most places. > > Gili I can't help but get in on this discussion thread. I starting using javax.comm from Sun and I've got a huge project that is entirely based on it now. Sun dropped support for windows which is a huge disappointment for me. I read Sun's page that if you want serial ports on Java with Windows, go to RXTX. I did this. In my experiments I've found by trial and error (and by discussion on this list) that under the hood, Sun javax.comm and RXTX gnu.io are completely different. So since Sun doesn't care about anyone who doesn't use their platforms (or at least anyone that uses Windows). I would argue that RXTX has no obligation to Sun. On another note, I have yet to see (or get) RXTX to work in my code that works perfectly fine using the old Sun javax.comm for windows binaries that I am forced to continue to run on. -------------- next part -------------- A non-text attachment was scrubbed... Name: talberts.vcf Type: text/x-vcard Size: 337 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20090415/a373e7f2/attachment-0005.vcf From cowwoc at bbs.darktech.org Wed Apr 15 13:13:03 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Wed, 15 Apr 2009 15:13:03 -0400 Subject: [Rxtx] Java5 support In-Reply-To: References: Message-ID: <49E631BF.9040501@bbs.darktech.org> > > A recent post reminded me of this old thread that I do not think got any > replies. > > Here is my take on the subject (of improving the API): > > Please do not 'improve' the API! > > Serial port is an old, simple and mature thing. Let's keep it that way. > Very little will be gained by 'improving' it. It is already too bad > that Sun spoiled the internals of javax.comm in version 3,0 so that the > gnu.io package had to be coined. That is a nuisance but nothing compared to > what happens if we start 'improve' the API and make it incompatible with > Java Comm API. > > Even additions should be resisted as this will encourage people to write > code that is not compatible with the 'standard' Java Comm API. The world > does not need more standards but better compliance to existing standards. > > If someone feels things like generics/iterators for are needed it is simple > to wrap the rxtx or java comm classes into classes to implement these > new language features without changing the API. > > rxtx us great and many thanks and cudos to the maintainers and creators but > it is lamentable that something this basic needs to be addressed outside > standard JRE. Not to mention being able to do basic USB stuff in Java/std > JRE in cross platform deployable fashion. > > br Kusti Hi Kusti, I must be missing something... I thought the entire point of forking off gnu.io was to innovate the API in a different direction than javax.comm, otherwise why wouldn't you stick to the standard API? Thanks, Gili From cowwoc at bbs.darktech.org Wed Apr 15 14:57:46 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Wed, 15 Apr 2009 16:57:46 -0400 Subject: [Rxtx] Timeout patch Message-ID: <49E64A4A.1050806@bbs.darktech.org> Hi, Please review the attached patch. - fixes disableReceiveTimeout() so reads now block until data is available. - receive timeouts and threshold handling is now more consistent across all implementations Gili -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: timeout.patch Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20090415/6815e522/attachment-0005.pl From bschlining at gmail.com Wed Apr 15 17:15:10 2009 From: bschlining at gmail.com (Brian Schlining) Date: Wed, 15 Apr 2009 16:15:10 -0700 Subject: [Rxtx] Timeout patch In-Reply-To: <49E64A4A.1050806@bbs.darktech.org> References: <49E64A4A.1050806@bbs.darktech.org> Message-ID: > > - fixes disableReceiveTimeout() so reads now block until data is available. Finally!! Thanks for submitting this patch. Hopefully it'll be integrated soon. Cheers -- B ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090415/a4143da7/attachment-0005.html From tristan.dyer at cgi.com Wed Apr 15 17:32:43 2009 From: tristan.dyer at cgi.com (Dyer, Tristan) Date: Wed, 15 Apr 2009 19:32:43 -0400 Subject: [Rxtx] Java5 support In-Reply-To: <49E631BF.9040501@bbs.darktech.org> References: <49E631BF.9040501@bbs.darktech.org> Message-ID: <9DA32B4D8579AF44AD96C1CC2E9C518D0346E9EB@MTL-MSG-02.cgiclients.com> That's weird. All I had to do to get my project running on RxTx was to change javax.comm to gnu.io I assume the reason for the fork to gnu.io was precisely to preserve compatibility with javax.comm. Unless Sun is willing to give you a TCK (or someone wants to pay for it) you wouldn't be able to provide any of the "new" javax.comm 3.0 feature set to windows and call it javax.comm, and as a side effect you get to keep the api consistent across platforms as well. Apache has been in a pissing fight with Sun for a couple years about this in regards to Harmony. As I remember rxtx was a lower level that suns CommAPI jar could talk to, to provide javax.comm on linux originally. With sun only providing CommAPI for some environments it became necessary to fork. At least that's how I assume it got here. Tristan -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of cowwoc Sent: Wednesday, April 15, 2009 4:13 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Java5 support > > A recent post reminded me of this old thread that I do not think got any > replies. > > Here is my take on the subject (of improving the API): > > Please do not 'improve' the API! > > Serial port is an old, simple and mature thing. Let's keep it that way. > Very little will be gained by 'improving' it. It is already too bad > that Sun spoiled the internals of javax.comm in version 3,0 so that the > gnu.io package had to be coined. That is a nuisance but nothing compared to > what happens if we start 'improve' the API and make it incompatible with > Java Comm API. > > Even additions should be resisted as this will encourage people to write > code that is not compatible with the 'standard' Java Comm API. The world > does not need more standards but better compliance to existing standards. > > If someone feels things like generics/iterators for are needed it is simple > to wrap the rxtx or java comm classes into classes to implement these > new language features without changing the API. > > rxtx us great and many thanks and cudos to the maintainers and creators but > it is lamentable that something this basic needs to be addressed outside > standard JRE. Not to mention being able to do basic USB stuff in Java/std > JRE in cross platform deployable fashion. > > br Kusti Hi Kusti, I must be missing something... I thought the entire point of forking off gnu.io was to innovate the API in a different direction than javax.comm, otherwise why wouldn't you stick to the standard API? Thanks, Gili _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Apr 15 17:48:20 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 15 Apr 2009 17:48:20 -0600 (MDT) Subject: [Rxtx] Timeout patch In-Reply-To: <49E64A4A.1050806@bbs.darktech.org> References: <49E64A4A.1050806@bbs.darktech.org> Message-ID: On Wed, 15 Apr 2009, cowwoc wrote: > Hi, > > Please review the attached patch. > > - fixes disableReceiveTimeout() so reads now block until data is available. > - receive timeouts and threshold handling is now more consistent across all > implementations > Hi Gili, This looks good to me. One 'minor' issue is that you are returning -1 instead of 0 now on timeout. It is fair to say timeouts are the same as the end of input but that is new behavior in rxtx we should warn existing users about so they can adjust their code. -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Wed Apr 15 17:52:46 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Wed, 15 Apr 2009 19:52:46 -0400 Subject: [Rxtx] Timeout patch In-Reply-To: References: <49E64A4A.1050806@bbs.darktech.org> Message-ID: <49E6734E.4010809@bbs.darktech.org> Actually returning -1 on timeout would be bug on my part. I believe that InputStream is expecting us to return 0 in such a case. Which part of my patch changes the return value? Thanks, Gili Trent Jarvi wrote: > On Wed, 15 Apr 2009, cowwoc wrote: > >> Hi, >> >> Please review the attached patch. >> >> - fixes disableReceiveTimeout() so reads now block until data is >> available. >> - receive timeouts and threshold handling is now more consistent >> across all implementations >> > > Hi Gili, > > This looks good to me. One 'minor' issue is that you are returning -1 > instead of 0 now on timeout. It is fair to say timeouts are the same as > the end of input but that is new behavior in rxtx we should warn > existing users about so they can adjust their code. > > -- > Trent Jarvi > tjarvi at qbang.org > From tjarvi at qbang.org Wed Apr 15 18:38:01 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 15 Apr 2009 18:38:01 -0600 (MDT) Subject: [Rxtx] Java5 support In-Reply-To: <9DA32B4D8579AF44AD96C1CC2E9C518D0346E9EB@MTL-MSG-02.cgiclients.com> References: <49E631BF.9040501@bbs.darktech.org> <9DA32B4D8579AF44AD96C1CC2E9C518D0346E9EB@MTL-MSG-02.cgiclients.com> Message-ID: The project isn't interested in breaking projects or changing the API. That said, we do allow some extensions to be added that are clearly marked as such. These extensions are all in the weird science category - they are not alternatives to doing what the API can already do or even something many people would want to use some of the time. The gnu.io namespace is used to avoid polluting of the javax.comm namespace. There are a number of reasons why we could be concerned about using javax.comm including political and/or legal questions but the main reason is a project like rxtx should do no harm. On Wed, 15 Apr 2009, Dyer, Tristan wrote: > That's weird. > > All I had to do to get my project running on RxTx was to change > javax.comm to gnu.io > > I assume the reason for the fork to gnu.io was precisely to preserve > compatibility with javax.comm. Unless Sun is willing to give you a TCK > (or someone wants to pay for it) you wouldn't be able to provide any of > the "new" javax.comm 3.0 feature set to windows and call it javax.comm, > and as a side effect you get to keep the api consistent across platforms > as well. Apache has been in a pissing fight with Sun for a couple years > about this in regards to Harmony. > > As I remember rxtx was a lower level that suns CommAPI jar could talk > to, to provide javax.comm on linux originally. With sun only providing > CommAPI for some environments it became necessary to fork. > > At least that's how I assume it got here. > > Tristan > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > Of cowwoc > Sent: Wednesday, April 15, 2009 4:13 PM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Java5 support > >> >> A recent post reminded me of this old thread that I do not think got > any >> replies. >> >> Here is my take on the subject (of improving the API): >> >> Please do not 'improve' the API! >> >> Serial port is an old, simple and mature thing. Let's keep it that > way. >> Very little will be gained by 'improving' it. It is already too bad >> that Sun spoiled the internals of javax.comm in version 3,0 so that > the >> gnu.io package had to be coined. That is a nuisance but nothing > compared to >> what happens if we start 'improve' the API and make it incompatible > with >> Java Comm API. >> >> Even additions should be resisted as this will encourage people to > write >> code that is not compatible with the 'standard' Java Comm API. The > world >> does not need more standards but better compliance to existing > standards. >> >> If someone feels things like generics/iterators for are needed it is > simple >> to wrap the rxtx or java comm classes into classes to implement these >> new language features without changing the API. >> >> rxtx us great and many thanks and cudos to the maintainers and > creators but >> it is lamentable that something this basic needs to be addressed > outside >> standard JRE. Not to mention being able to do basic USB stuff in > Java/std >> JRE in cross platform deployable fashion. >> >> br Kusti > > Hi Kusti, > > I must be missing something... I thought the entire point of forking > > off gnu.io was to innovate the API in a different direction than > javax.comm, otherwise why wouldn't you stick to the standard API? > > Thanks, > Gili > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Wed Apr 15 18:53:42 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 15 Apr 2009 18:53:42 -0600 (MDT) Subject: [Rxtx] Timeout patch In-Reply-To: <49E6734E.4010809@bbs.darktech.org> References: <49E64A4A.1050806@bbs.darktech.org> <49E6734E.4010809@bbs.darktech.org> Message-ID: Hi Gili, I guess the documentation just needs to be clear and consistant (which it really wasn't before). This is what caught my eye but looking above it, I see the previous documentation mentions -1 in places too. -*timeout threshold Behavior -*------------------------------------------------------------------------ -*0 0 blocks until 1 byte is available -*>0 0 blocks until timeout occurs, returns 0 on timeout -*>0 >0 blocks until timeout or reads threshold bytes, - returns 0 on timeout -*0 >0 blocks until reads threshold bytes - */ + * timeout threshold Behavior + * --------------------------------------------------------------------------- + * < 0 <= 0 blocks until any data is available. + * < 0 > 0 blocks until {@code min(threshold, b.len)} bytes are available. + * >=0 <=0 blocks for {@code timeout} ms or until any data is available. Returns -1 on timeout. + * >=0 > 0 blocks for {@code timeout} ms or until {@code min(threshold, b.len)} bytes are available. Returns -1 on timeout. On Wed, 15 Apr 2009, cowwoc wrote: > > Actually returning -1 on timeout would be bug on my part. I believe > that InputStream is expecting us to return 0 in such a case. Which part of my > patch changes the return value? > > Thanks, > Gili > > Trent Jarvi wrote: >> On Wed, 15 Apr 2009, cowwoc wrote: >> >>> Hi, >>> >>> Please review the attached patch. >>> >>> - fixes disableReceiveTimeout() so reads now block until data is >>> available. >>> - receive timeouts and threshold handling is now more consistent across >>> all implementations >>> >> >> Hi Gili, >> >> This looks good to me. One 'minor' issue is that you are returning -1 >> instead of 0 now on timeout. It is fair to say timeouts are the same as >> the end of input but that is new behavior in rxtx we should warn existing >> users about so they can adjust their code. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> > From cowwoc at bbs.darktech.org Wed Apr 15 19:26:28 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Wed, 15 Apr 2009 21:26:28 -0400 Subject: [Rxtx] Timeout patch In-Reply-To: References: <49E64A4A.1050806@bbs.darktech.org> <49E6734E.4010809@bbs.darktech.org> Message-ID: <49E68944.3050808@bbs.darktech.org> Hi Trent, Please modify the Javadoc to read that timeouts will return 0. PS: The rxtx source contains plenty of ... questionable ... lines of code. The following items come to mind: 1) In serial_read() we return -1 on various error codes instead of throwing the appropriate exception back into the Java layer. 2) Some Java methods print error messages to stdout instead of throwing exceptions on invalid input. 3) #ifdef LIFE_IS_GOOD (is this ever used?) and "/* Baby did a bad baad thing */". Ifdef and comments like this litter the code. 4) Most files use C-language instead of C++. I am not advocating fancy C++ but rather C code wrapped in objects. Moving variable declarations closer to their usage and perhaps grouping related methods into cohesive classes would improve readability. I know this is an open-source project, but the quality of the code freaks me out :) Is there any resistance to fixing some of these problems? Gili Trent Jarvi wrote: > > Hi Gili, > > I guess the documentation just needs to be clear and consistant (which > it really wasn't before). This is what caught my eye but looking > above it, I see the previous documentation mentions -1 in places too. > > -*timeout threshold Behavior > -*------------------------------------------------------------------------ > > -*0 0 blocks until 1 byte is available > -*>0 0 blocks until timeout occurs, returns 0 on timeout > -*>0 >0 blocks until timeout or reads threshold bytes, > - returns 0 on timeout > -*0 >0 blocks until reads threshold bytes > - */ > + * timeout threshold Behavior > + * > --------------------------------------------------------------------------- > > + * < 0 <= 0 blocks until any data is available. > + * < 0 > 0 blocks until {@code min(threshold, > b.len)} bytes are available. > + * >=0 <=0 blocks for {@code timeout} ms or until > any data is available. Returns -1 on timeout. > + * >=0 > 0 blocks for {@code timeout} ms or until > {@code min(threshold, b.len)} bytes are available. Returns -1 on timeout. > > > > On Wed, 15 Apr 2009, cowwoc wrote: > >> >> Actually returning -1 on timeout would be bug on my part. I >> believe that InputStream is expecting us to return 0 in such a case. >> Which part of my patch changes the return value? >> >> Thanks, >> Gili >> >> Trent Jarvi wrote: >>> On Wed, 15 Apr 2009, cowwoc wrote: >>> >>>> Hi, >>>> >>>> Please review the attached patch. >>>> >>>> - fixes disableReceiveTimeout() so reads now block until data is >>>> available. >>>> - receive timeouts and threshold handling is now more consistent >>>> across all implementations >>>> >>> >>> Hi Gili, >>> >>> This looks good to me. One 'minor' issue is that you are returning >>> -1 instead of 0 now on timeout. It is fair to say timeouts are the >>> same as the end of input but that is new behavior in rxtx we should >>> warn existing users about so they can adjust their code. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >> From cowwoc at bbs.darktech.org Wed Apr 15 19:30:08 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Wed, 15 Apr 2009 21:30:08 -0400 Subject: [Rxtx] Java5 support In-Reply-To: References: <49E631BF.9040501@bbs.darktech.org> <9DA32B4D8579AF44AD96C1CC2E9C518D0346E9EB@MTL-MSG-02.cgiclients.com> Message-ID: <49E68A20.80209@bbs.darktech.org> Trent Jarvi wrote: > The project isn't interested in breaking projects or changing the API. > That said, we do allow some extensions to be added that are clearly marked > as such. These extensions are all in the weird science category - they > are not alternatives to doing what the API can already do or even > something many people would want to use some of the time. We could define rxtx-specific classes in gnu.io that extend those in javax.comm so users would enjoy both backwards compatibility as well as rxtx-specific extensions. > The gnu.io namespace is used to avoid polluting of the javax.comm > namespace. There are a number of reasons why we could be concerned about > using javax.comm including political and/or legal questions but the main > reason is a project like rxtx should do no harm. Did anyone from Sun \take issue with the aforementioned approach (gnu.io extending javax.comm)? Gili > On Wed, 15 Apr 2009, Dyer, Tristan wrote: > >> That's weird. >> >> All I had to do to get my project running on RxTx was to change >> javax.comm to gnu.io >> >> I assume the reason for the fork to gnu.io was precisely to preserve >> compatibility with javax.comm. Unless Sun is willing to give you a TCK >> (or someone wants to pay for it) you wouldn't be able to provide any of >> the "new" javax.comm 3.0 feature set to windows and call it javax.comm, >> and as a side effect you get to keep the api consistent across platforms >> as well. Apache has been in a pissing fight with Sun for a couple years >> about this in regards to Harmony. >> >> As I remember rxtx was a lower level that suns CommAPI jar could talk >> to, to provide javax.comm on linux originally. With sun only providing >> CommAPI for some environments it became necessary to fork. >> >> At least that's how I assume it got here. >> >> Tristan >> >> >> -----Original Message----- >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >> Of cowwoc >> Sent: Wednesday, April 15, 2009 4:13 PM >> To: rxtx at qbang.org >> Subject: Re: [Rxtx] Java5 support >> >>> A recent post reminded me of this old thread that I do not think got >> any >>> replies. >>> >>> Here is my take on the subject (of improving the API): >>> >>> Please do not 'improve' the API! >>> >>> Serial port is an old, simple and mature thing. Let's keep it that >> way. >>> Very little will be gained by 'improving' it. It is already too bad >>> that Sun spoiled the internals of javax.comm in version 3,0 so that >> the >>> gnu.io package had to be coined. That is a nuisance but nothing >> compared to >>> what happens if we start 'improve' the API and make it incompatible >> with >>> Java Comm API. >>> >>> Even additions should be resisted as this will encourage people to >> write >>> code that is not compatible with the 'standard' Java Comm API. The >> world >>> does not need more standards but better compliance to existing >> standards. >>> If someone feels things like generics/iterators for are needed it is >> simple >>> to wrap the rxtx or java comm classes into classes to implement these >>> new language features without changing the API. >>> >>> rxtx us great and many thanks and cudos to the maintainers and >> creators but >>> it is lamentable that something this basic needs to be addressed >> outside >>> standard JRE. Not to mention being able to do basic USB stuff in >> Java/std >>> JRE in cross platform deployable fashion. >>> >>> br Kusti >> Hi Kusti, >> >> I must be missing something... I thought the entire point of forking >> >> off gnu.io was to innovate the API in a different direction than >> javax.comm, otherwise why wouldn't you stick to the standard API? >> >> Thanks, >> Gili >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Apr 15 20:19:01 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 15 Apr 2009 20:19:01 -0600 (MDT) Subject: [Rxtx] Timeout patch In-Reply-To: <49E68944.3050808@bbs.darktech.org> References: <49E64A4A.1050806@bbs.darktech.org> <49E6734E.4010809@bbs.darktech.org> <49E68944.3050808@bbs.darktech.org> Message-ID: Hi Gili, Your glowing review obviously means you have not read termios.c :) I'm not against the type of changes like you suggest. I do think they will need bake time and we have people waiting for what we have now. Putting proactive changes in the following release would be fine. The returning -1 issues are wrong and should be fixed. We can do that now. Regarding C/C++, I think the best thing to do for this project is push as much logic as is possible out of the C files and into Java. Use Java for the objects and C to perform as little as possible. This is a compromise in a sense; C++ is perfectly fine and would work. C++ could even be easier to read and probably would avoid some bugs - especial with C strings. I really don't want to build g++ cross compilers for all the platforms we do in the ToyBox. In practice, adding g++ into the mix is an order of magnitude harder to get working. If we can avoid using C++ completely, there is a measurable advantage in what we can easily deliver. http://rxtx.qbang.org//ToyBox Proof of concept: http://rxtx.qbang.org/ToyBox/2.1-7-build1/Linux/glibc-2.3.5/ On Wed, 15 Apr 2009, cowwoc wrote: > Hi Trent, > > Please modify the Javadoc to read that timeouts will return 0. > > PS: The rxtx source contains plenty of ... questionable ... lines of code. > The following items come to mind: > > 1) In serial_read() we return -1 on various error codes instead of throwing > the appropriate exception back into the Java layer. > 2) Some Java methods print error messages to stdout instead of throwing > exceptions on invalid input. > 3) #ifdef LIFE_IS_GOOD (is this ever used?) and "/* Baby did a bad baad > thing */". Ifdef and comments like this litter the code. > 4) Most files use C-language instead of C++. I am not advocating fancy C++ > but rather C code wrapped in objects. Moving variable declarations closer to > their usage and perhaps grouping related methods into cohesive classes would > improve readability. > > I know this is an open-source project, but the quality of the code > freaks me out :) Is there any resistance to fixing some of these problems? > > Gili > > Trent Jarvi wrote: >> >> Hi Gili, >> >> I guess the documentation just needs to be clear and consistant (which it >> really wasn't before). This is what caught my eye but looking above it, I >> see the previous documentation mentions -1 in places too. >> >> -*timeout threshold Behavior >> -*------------------------------------------------------------------------ >> -*0 0 blocks until 1 byte is available >> -*>0 0 blocks until timeout occurs, returns 0 on timeout >> -*>0 >0 blocks until timeout or reads threshold bytes, >> - returns 0 on timeout >> -*0 >0 blocks until reads threshold bytes >> - */ >> + * timeout threshold Behavior >> + * >> --------------------------------------------------------------------------- >> + * < 0 <= 0 blocks until any data is available. >> + * < 0 > 0 blocks until {@code min(threshold, b.len)} >> bytes are available. >> + * >=0 <=0 blocks for {@code timeout} ms or until any >> data is available. Returns -1 on timeout. >> + * >=0 > 0 blocks for {@code timeout} ms or until {@code >> min(threshold, b.len)} bytes are available. Returns -1 on timeout. >> >> >> >> On Wed, 15 Apr 2009, cowwoc wrote: >> >>> >>> Actually returning -1 on timeout would be bug on my part. I believe >>> that InputStream is expecting us to return 0 in such a case. Which part of >>> my patch changes the return value? >>> >>> Thanks, >>> Gili >>> >>> Trent Jarvi wrote: >>>> On Wed, 15 Apr 2009, cowwoc wrote: >>>> >>>>> Hi, >>>>> >>>>> Please review the attached patch. >>>>> >>>>> - fixes disableReceiveTimeout() so reads now block until data is >>>>> available. >>>>> - receive timeouts and threshold handling is now more consistent across >>>>> all implementations >>>>> >>>> >>>> Hi Gili, >>>> >>>> This looks good to me. One 'minor' issue is that you are returning -1 >>>> instead of 0 now on timeout. It is fair to say timeouts are the same as >>>> the end of input but that is new behavior in rxtx we should warn existing >>>> users about so they can adjust their code. >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> >>> > From tjarvi at qbang.org Wed Apr 15 21:38:29 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 15 Apr 2009 21:38:29 -0600 (MDT) Subject: [Rxtx] Java5 support In-Reply-To: <49E68A20.80209@bbs.darktech.org> References: <49E631BF.9040501@bbs.darktech.org> <9DA32B4D8579AF44AD96C1CC2E9C518D0346E9EB@MTL-MSG-02.cgiclients.com> <49E68A20.80209@bbs.darktech.org> Message-ID: On Wed, 15 Apr 2009, cowwoc wrote: > Trent Jarvi wrote: >> The project isn't interested in breaking projects or changing the API. That >> said, we do allow some extensions to be added that are clearly marked as >> such. These extensions are all in the weird science category - they are >> not alternatives to doing what the API can already do or even something >> many people would want to use some of the time. > > We could define rxtx-specific classes in gnu.io that extend those in > javax.comm so users would enjoy both backwards compatibility as well as > rxtx-specific extensions. > >> The gnu.io namespace is used to avoid polluting of the javax.comm >> namespace. There are a number of reasons why we could be concerned about >> using javax.comm including political and/or legal questions but the main >> reason is a project like rxtx should do no harm. > > Did anyone from Sun \take issue with the aforementioned approach > (gnu.io extending javax.comm)? > It would take more than an opinion from someone at Sun before we moved like that. javax.comm (a namespace grandfathered into the JSR) is a broken namespace with a special 'generic' legacy release that may be discontinued at any time. The people using rxtx are interested in what javax.comm was in version 2.0. Not the 3.0 currently offered which appears to be a quick fix for a business need Sun satisfied on Solaris. Why would we ever depend upon (extend) this namespace? -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Thu Apr 16 10:38:42 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Thu, 16 Apr 2009 12:38:42 -0400 Subject: [Rxtx] Java5 support In-Reply-To: References: <49E631BF.9040501@bbs.darktech.org> <9DA32B4D8579AF44AD96C1CC2E9C518D0346E9EB@MTL-MSG-02.cgiclients.com> <49E68A20.80209@bbs.darktech.org> Message-ID: <49E75F12.7010603@bbs.darktech.org> Trent Jarvi wrote: > It would take more than an opinion from someone at Sun before we moved > like that. > > javax.comm (a namespace grandfathered into the JSR) is a broken > namespace with a special 'generic' legacy release that may be > discontinued at any time. The people using rxtx are interested in what > javax.comm was in version 2.0. Not the 3.0 currently offered which > appears to be a quick fix for a business need Sun satisfied on Solaris. > > Why would we ever depend upon (extend) this namespace? I was under the impression that javax.comm 3.0 was backwards compatible against 2.0... What changes in 3.0 do the rxtx folk object to? The way I see it, gnu.io suffers from the following pain points: 1) Not backwards compatible with standard API 2) Non-existent Javadoc for most of the API 3) Tiny community base, non-existent commercial support, questionable code quality. I still don't understand enough about the reasoning behind the namespace fork. I'm all for forking if we take the opportunity to innovate the API, but if you're going to keep it almost identical I'd be in favor of just having gnu.io extend javax.comm. Again, I might change my mind once I understand your reasoning better but that's how I feel now. Gili From bschlining at gmail.com Thu Apr 16 12:04:05 2009 From: bschlining at gmail.com (Brian Schlining) Date: Thu, 16 Apr 2009 11:04:05 -0700 Subject: [Rxtx] Java5 support In-Reply-To: <49E75F12.7010603@bbs.darktech.org> References: <49E631BF.9040501@bbs.darktech.org> <9DA32B4D8579AF44AD96C1CC2E9C518D0346E9EB@MTL-MSG-02.cgiclients.com> <49E68A20.80209@bbs.darktech.org> <49E75F12.7010603@bbs.darktech.org> Message-ID: > > > I was under the impression that javax.comm 3.0 was backwards > compatible > against 2.0... What changes in 3.0 do the rxtx folk object to? I haven't tried 3.0, since my target platforms are usually Mac or Windows. I can say that when Sun dropped Windows support of Javacomm, it was quite a slap in the face. The real kicker was that they removed the downloads for version 2.0 too. So that left folks who were using Sun's API in a pickle. > > The way I see it, gnu.io suffers from the following pain points: > > 1) Not backwards compatible with standard API Hmmm, not exactly true. When Sun removed Javacomm 2.0, RXTX was a real savior, I only had to change the namespace in my code and everything worked. > 2) Non-existent Javadoc for most of the API Sort of. Since RXTX's API is the same as Sun's, code examples and Javadocs from Sun's stuff do apply to RXTX. > 3) Tiny community base, non-existent commercial support, questionable > code quality. You really should back those assertions up with facts before make them. I can think of a number of projects here at my employer that use RXTX, so we really appreciate Trent's work as well as all the folks who have contributed patches. If you want commercial support I'm sure that if you offered enough money, Trent would work something out with you ;-). Also, there's always http://serialio.com/products/serialport/serialport.php As to the code quality, the project is open source, feel free to contribute fixes. > I still don't understand enough about the reasoning behind the > namespace fork. I'm all for forking if we take the opportunity to > innovate the API, but if you're going to keep it almost identical I'd be > in favor of just having gnu.io extend javax.comm. Again, I might change > my mind once I understand your reasoning better but that's how I feel now. > As to extending/innovating the API, RXTX is an open-source project. You can always take the code base and fork it to suit your needs, as long as you adhere to the LGPL license. Cheers -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090416/32cb4447/attachment-0004.html From paul at cometway.com Thu Apr 16 12:56:35 2009 From: paul at cometway.com (Paul Cunningham) Date: Thu, 16 Apr 2009 14:56:35 -0400 Subject: [Rxtx] Java5 support Message-ID: <91BF244D-07E4-4B30-9F9D-0DC0964045B4@cometway.com> I've been a steady lurker on this board for years and have to agree with Brian here: 1) RXTX was a savior -- long before javax.comm was dropped from Sun's repertoire. For Mac OS X users it's the ONLY option. Serial port support on the Mac has always been a sore spot for me. 2) There's nothing complicated about the javax.comm APIs and they are well Javadoc'ed all over the web. RXTX adherence to them has been very consistent. 3) RS-232 with Java is a tiny community period. If you are reading this, I'm sorry but you are a freak. Anyone doing RS-232 for unknown device "x" is a member of an even tinier community with practically no support whatsoever. However this RXTX list community is extremely well supported and every important question is addressed quickly, personally and in great detail by Trent himself. You can't get support like that from most "commercial" operations and we certainly never got that from commercial entities like Sun. Nobody here is going to hold your hand, but we will point you to any available resources that aren't already clearly spelled out on the RXTX page. You might have to learn how to download and build the package for yourself to get the latest updates and fixes, but that's just par for the course. -pc On Apr 16, 2009, at 2:04 PM, Brian Schlining wrote: > > I was under the impression that javax.comm 3.0 was backwards > compatible > against 2.0... What changes in 3.0 do the rxtx folk object to? > > I haven't tried 3.0, since my target platforms are usually Mac or > Windows. I can say that when Sun dropped Windows support of > Javacomm, it was quite a slap in the face. The real kicker was that > they removed the downloads for version 2.0 too. So that left folks > who were using Sun's API in a pickle. > > > The way I see it, gnu.io suffers from the following pain > points: > > 1) Not backwards compatible with standard API > > Hmmm, not exactly true. When Sun removed Javacomm 2.0, RXTX was a > real savior, I only had to change the namespace in my code and > everything worked. > > 2) Non-existent Javadoc for most of the API > > Sort of. Since RXTX's API is the same as Sun's, code examples and > Javadocs from Sun's stuff do apply to RXTX. > > 3) Tiny community base, non-existent commercial support, questionable > code quality. > > You really should back those assertions up with facts before make > them. > > I can think of a number of projects here at my employer that use > RXTX, so we really appreciate Trent's work as well as all the folks > who have contributed patches. If you want commercial support I'm > sure that if you offered enough money, Trent would work something > out with you ;-). Also, there's always http://serialio.com/products/serialport/serialport.php > > As to the code quality, the project is open source, feel free to > contribute fixes. > > I still don't understand enough about the reasoning behind the > namespace fork. I'm all for forking if we take the opportunity to > innovate the API, but if you're going to keep it almost identical > I'd be > in favor of just having gnu.io extend javax.comm. Again, I might > change > my mind once I understand your reasoning better but that's how I > feel now. > > As to extending/innovating the API, RXTX is an open-source project. > You can always take the code base and fork it to suit your needs, as > long as you adhere to the LGPL license. > > Cheers > > -- > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > Brian Schlining > bschlining at gmail.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090416/dd8eda0b/attachment-0004.html From cowwoc at bbs.darktech.org Thu Apr 16 14:07:41 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Thu, 16 Apr 2009 16:07:41 -0400 Subject: [Rxtx] Java5 support In-Reply-To: <91BF244D-07E4-4B30-9F9D-0DC0964045B4@cometway.com> References: <91BF244D-07E4-4B30-9F9D-0DC0964045B4@cometway.com> Message-ID: <49E7900D.3060100@bbs.darktech.org> Paul Cunningham wrote: > 2) There's nothing complicated about the javax.comm APIs and they are > well Javadoc'ed all over the web. RXTX adherence to them has been very > consistent. The fact that javax.comm has good Javadoc does not mean that gnu.io does. The latter has little or no Javadoc. Yes we could assume that gnu.io's documentation is identical to javax.comm but the fact remains that code-completion won't bring up Javadoc for gnu.io. Secondly, someone mentioned recently that although the APIs are supposed to be the same, RXTX in fact behaves noticeably different from javax.comm. The gnu.io specification needs to be nailed down one way or the other. Gili From bschlining at gmail.com Thu Apr 16 14:25:38 2009 From: bschlining at gmail.com (Brian Schlining) Date: Thu, 16 Apr 2009 13:25:38 -0700 Subject: [Rxtx] Java5 support In-Reply-To: <49E7900D.3060100@bbs.darktech.org> References: <91BF244D-07E4-4B30-9F9D-0DC0964045B4@cometway.com> <49E7900D.3060100@bbs.darktech.org> Message-ID: > > The fact that javax.comm has good Javadoc does not mean that gnu.io > does. The latter has little or no Javadoc. Yes we could assume that > gnu.io's documentation is identical to javax.comm but the fact remains > that code-completion won't bring up Javadoc for gnu.io. Gili, perhaps a highly motivated person, such as yourself, could fill in the Javadocs and contribute the patches back to RXTX? -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090416/79502619/attachment-0004.html From cowwoc at bbs.darktech.org Thu Apr 16 14:47:27 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Thu, 16 Apr 2009 16:47:27 -0400 Subject: [Rxtx] Java5 support In-Reply-To: References: <91BF244D-07E4-4B30-9F9D-0DC0964045B4@cometway.com> <49E7900D.3060100@bbs.darktech.org> Message-ID: <49E7995F.1020304@bbs.darktech.org> Brian, I have already submitted two patches for RXTX in the past week alone... I understand that Sun's decision to drop Windows and Mac support angered quite a few people but I fail to see the link between the reference implementation (which angered you) and the specification (which by all accounts is great). Why not extend their specification and completely replace the implementation? From what I've read, javax.comm 3.0's API is completely backwards compatible to 2.0. On the flip side, if you're not interested in extending javax.comm, why not refactor the gnu.io package to improve usability and I would be more than happy to contribute a completely new Javadoc. Gili Brian Schlining wrote: > The fact that javax.comm has good Javadoc does not mean that > gnu.io > does. The latter has little or no Javadoc. Yes we could assume that > gnu.io 's documentation is identical to javax.comm > but the fact remains > that code-completion won't bring up Javadoc for gnu.io . > > > Gili, perhaps a highly motivated person, such as yourself, could fill in > the Javadocs and contribute the patches back to RXTX? > > -- > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > Brian Schlining > bschlining at gmail.com From talberts at msiscales.com Thu Apr 16 14:55:50 2009 From: talberts at msiscales.com (Tim Alberts) Date: Thu, 16 Apr 2009 13:55:50 -0700 Subject: [Rxtx] RXTX Simple Demo Program Message-ID: <49E79B56.5010604@msiscales.com> I don't think it exists yet, so I'd like to propose it be done. I would like to see a demo program that opens a serial port and allows transmitting/receiving of data and configuration of ports via the RXTX gnu.io software. One of the features that was driving me to move to RXTX (aside from Sun dropping support), was the upcoming ability to use web install. I have not kept up so I'm not sure yet if that is implemented, but if/when it is, a demo program to distribute via web install would be outstanding to see from RXTX. I know that Sun has (had) a blackbox demo program that tries to open every available serial port it finds on the computer and allows for transmit/receive and configuration of the serial port. This is pretty much what I have in mind for RXTX. Is this a reasonable request? -------------- next part -------------- A non-text attachment was scrubbed... Name: talberts.vcf Type: text/x-vcard Size: 337 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20090416/3986518c/attachment-0004.vcf From tjarvi at qbang.org Thu Apr 16 14:56:35 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Apr 2009 14:56:35 -0600 (MDT) Subject: [Rxtx] Java5 support In-Reply-To: <49E7900D.3060100@bbs.darktech.org> References: <91BF244D-07E4-4B30-9F9D-0DC0964045B4@cometway.com> <49E7900D.3060100@bbs.darktech.org> Message-ID: On Thu, 16 Apr 2009, cowwoc wrote: > Paul Cunningham wrote: >> 2) There's nothing complicated about the javax.comm APIs and they are >> well Javadoc'ed all over the web. RXTX adherence to them has been very >> consistent. > > The fact that javax.comm has good Javadoc does not mean that gnu.io > does. The latter has little or no Javadoc. Yes we could assume that > gnu.io's documentation is identical to javax.comm but the fact remains > that code-completion won't bring up Javadoc for gnu.io. Secondly, > someone mentioned recently that although the APIs are supposed to be the > same, RXTX in fact behaves noticeably different from javax.comm. The > gnu.io specification needs to be nailed down one way or the other. > Hi Gili RXTX treats the javax.comm v2.0 API docs as the truth. When rxtx does not behave like the docs say, we treat it as a bug. If the bug really bothers someone, they fix it. That said, there will be behavior differences between the implementations. RXTX is not a 'bug per bug' implementation of javax.comm. Many default settings are not documented and can differ also. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Apr 16 15:47:24 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Apr 2009 15:47:24 -0600 (MDT) Subject: [Rxtx] Java5 support In-Reply-To: <49E7995F.1020304@bbs.darktech.org> References: <91BF244D-07E4-4B30-9F9D-0DC0964045B4@cometway.com> <49E7900D.3060100@bbs.darktech.org> <49E7995F.1020304@bbs.darktech.org> Message-ID: On Thu, 16 Apr 2009, cowwoc wrote: > On the flip side, if you're not interested in extending javax.comm, why > not refactor the gnu.io package to improve usability and I would be more > than happy to contribute a completely new Javadoc. Hi Gili, Changing the API to use the latest offerings in JREs is not in itself a good reason to break an API. If the functionality is there, this library is better off not changing because many applications count on that API remaining stable. If you have some usability issues that hold merit beyond your personal preferences and make sense to most of the people here, RXTX can change if it is obviously the right thing to do. -- Trent Jarvi tjarvi at qbang.org From paul at cometway.com Thu Apr 16 15:52:18 2009 From: paul at cometway.com (Paul Cunningham) Date: Thu, 16 Apr 2009 17:52:18 -0400 Subject: [Rxtx] Java5 support In-Reply-To: <49E7900D.3060100@bbs.darktech.org> References: <91BF244D-07E4-4B30-9F9D-0DC0964045B4@cometway.com> <49E7900D.3060100@bbs.darktech.org> Message-ID: <9146C76F-17D8-468D-A0F2-CAC9512BCDD6@cometway.com> Code completion... isn't that where you stub out some methods, check it into CVS, and the next day find out that someone else finished your work? ;-) Seemingly your project has exposed RXTX to more finicky devices than the ones I have worked with. I can understand why better Javadocs would be useful if you are using IDEs as a tool to learn and remember your APIs, and you sound qualified enough to contribute information about the kinds of idiosyncrasies between javax.comm and gui.io to the RXTX project. I also understand that you have read the javax.comm 3.0 APIs and are upset that no one has actually implemented them. An updated specification and your keen interest in seeing it implemented is apparently not enough to make that happen in a world where RS-232 is only used for legacy support of devices with no hope for firmware updates. -pc On Apr 16, 2009, at 4:07 PM, cowwoc wrote: > Paul Cunningham wrote: >> 2) There's nothing complicated about the javax.comm APIs and they >> are well Javadoc'ed all over the web. RXTX adherence to them has >> been very consistent. > > The fact that javax.comm has good Javadoc does not mean that gnu.io > does. The latter has little or no Javadoc. Yes we could assume that > gnu.io's documentation is identical to javax.comm but the fact > remains that code-completion won't bring up Javadoc for gnu.io. > Secondly, someone mentioned recently that although the APIs are > supposed to be the same, RXTX in fact behaves noticeably different > from javax.comm. The gnu.io specification needs to be nailed down > one way or the other. > > Gili > > From paul at cometway.com Thu Apr 16 16:14:16 2009 From: paul at cometway.com (Paul Cunningham) Date: Thu, 16 Apr 2009 18:14:16 -0400 Subject: [Rxtx] Java5 support In-Reply-To: <9146C76F-17D8-468D-A0F2-CAC9512BCDD6@cometway.com> References: <91BF244D-07E4-4B30-9F9D-0DC0964045B4@cometway.com> <49E7900D.3060100@bbs.darktech.org> <9146C76F-17D8-468D-A0F2-CAC9512BCDD6@cometway.com> Message-ID: <47F476E8-5F95-4521-A437-11622583210F@cometway.com> btw, i mean no disrespect to anyone actively developing an RS-232 interfaces for new devices. in fact my most recent project involved a freescale chip using a UART- to-USB chip, as i have no idea how to go about interfacing USB devices to Java. RXTX behaved very well, even when the USB driver didn't. is there anything resembling javax.comm for USB? -pc On Apr 16, 2009, at 5:52 PM, Paul Cunningham wrote: > in a world where RS-232 is > only used for legacy support of devices with no hope for firmware > updates. From tjarvi at qbang.org Thu Apr 16 16:50:12 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Apr 2009 16:50:12 -0600 (MDT) Subject: [Rxtx] Java5 support In-Reply-To: <47F476E8-5F95-4521-A437-11622583210F@cometway.com> References: <91BF244D-07E4-4B30-9F9D-0DC0964045B4@cometway.com> <49E7900D.3060100@bbs.darktech.org> <9146C76F-17D8-468D-A0F2-CAC9512BCDD6@cometway.com> <47F476E8-5F95-4521-A437-11622583210F@cometway.com> Message-ID: Hi Paul, JSR 80 is USB HID support. http://javax-usb.org/ http://jcp.org/aboutJava/communityprocess/final/jsr080/index.html On Thu, 16 Apr 2009, Paul Cunningham wrote: > btw, i mean no disrespect to anyone actively developing an RS-232 > interfaces for new devices. > > in fact my most recent project involved a freescale chip using a UART- > to-USB chip, as i have no idea how to go about interfacing USB devices > to Java. RXTX behaved very well, even when the USB driver didn't. > > is there anything resembling javax.comm for USB? -pc > > > On Apr 16, 2009, at 5:52 PM, Paul Cunningham wrote: > >> in a world where RS-232 is >> only used for legacy support of devices with no hope for firmware >> updates. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From cowwoc at bbs.darktech.org Thu Apr 16 16:57:43 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Thu, 16 Apr 2009 18:57:43 -0400 Subject: [Rxtx] Java5 support In-Reply-To: References: <91BF244D-07E4-4B30-9F9D-0DC0964045B4@cometway.com> <49E7900D.3060100@bbs.darktech.org> <9146C76F-17D8-468D-A0F2-CAC9512BCDD6@cometway.com> <47F476E8-5F95-4521-A437-11622583210F@cometway.com> Message-ID: <49E7B7E7.9050302@bbs.darktech.org> Last time I looked this, there was no usable Windows version. Gili Trent Jarvi wrote: > Hi Paul, > > JSR 80 is USB HID support. > > http://javax-usb.org/ > http://jcp.org/aboutJava/communityprocess/final/jsr080/index.html > > On Thu, 16 Apr 2009, Paul Cunningham wrote: > >> btw, i mean no disrespect to anyone actively developing an RS-232 >> interfaces for new devices. >> >> in fact my most recent project involved a freescale chip using a UART- >> to-USB chip, as i have no idea how to go about interfacing USB devices >> to Java. RXTX behaved very well, even when the USB driver didn't. >> >> is there anything resembling javax.comm for USB? -pc >> >> >> On Apr 16, 2009, at 5:52 PM, Paul Cunningham wrote: >> >>> in a world where RS-232 is >>> only used for legacy support of devices with no hope for firmware >>> updates. >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Apr 16 17:02:49 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Apr 2009 17:02:49 -0600 (MDT) Subject: [Rxtx] RXTX Simple Demo Program In-Reply-To: <49E79B56.5010604@msiscales.com> References: <49E79B56.5010604@msiscales.com> Message-ID: On Thu, 16 Apr 2009, Tim Alberts wrote: > I don't think it exists yet, so I'd like to propose it be done. I would like > to see a demo program that opens a serial port and allows > transmitting/receiving of data and configuration of ports via the RXTX gnu.io > software. > > One of the features that was driving me to move to RXTX (aside from Sun > dropping support), was the upcoming ability to use web install. I have not > kept up so I'm not sure yet if that is implemented, but if/when it is, a demo > program to distribute via web install would be outstanding to see from RXTX. > > I know that Sun has (had) a blackbox demo program that tries to open every > available serial port it finds on the computer and allows for > transmit/receive and configuration of the serial port. This is pretty much > what I have in mind for RXTX. > > Is this a reasonable request? > Hi Tim, It is a great request. I don't know if anyone will write tha application though. We could include it with rxtx as a demo like BlackBox was with Sun's commapi. But.. You can run Sun's BlackBox source code through the ChangePackage.sh and use BlackBox with rxtx 2.1/2.2 for personal use. ChangePackage.sh is in the contrib directory with the rxtx source code. As I recall, there was just one minor modification required - BlackBox had a hard coded number of ports which could cause problems. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Apr 16 20:25:29 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Apr 2009 20:25:29 -0600 (MDT) Subject: [Rxtx] Timeout patch In-Reply-To: <49E64A4A.1050806@bbs.darktech.org> References: <49E64A4A.1050806@bbs.darktech.org> Message-ID: On Wed, 15 Apr 2009, cowwoc wrote: > Hi, > > Please review the attached patch. > > - fixes disableReceiveTimeout() so reads now block until data is available. > - receive timeouts and threshold handling is now more consistent across all > implementations > Attached is the core change to serial Gili has suggested. I ran tests that cover about 40% of the serial code without regressions. If you happen to use the same 40%, you are safe :) Otherwise, I suggest trying the changes. I'd like to hear if this fixes issues for anyone. I put some binaries for win32, Mac and linux32 here: ftp://ftp.qbang.org/pub/rxtx/test-timeout.zip Unfortunately, The original patch tries to do several things. Some of the changes are not correct and require further review. This is just the timeout portion for serial code which I've reviewed and tested. -- Trent Jarvi tjarvi at qbang.org -------------- next part -------------- Index: src/SerialImp.c =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/SerialImp.c,v retrieving revision 1.46.2.203 diff -u -r1.46.2.203 SerialImp.c --- src/SerialImp.c 19 Mar 2009 03:27:48 -0000 1.46.2.203 +++ src/SerialImp.c 17 Apr 2009 02:05:48 -0000 @@ -3298,6 +3298,8 @@ if (vtime < 0){ timeout = 0; + if (threshold <= 0) + threshold = 1; } else if (vtime == 0){ timeout = 1; Index: src/gnu/io/RXTXPort.java =================================================================== RCS file: /usr/local/cvsroot/rxtx-devel/src/gnu/io/RXTXPort.java,v retrieving revision 1.27.2.76 diff -u -r1.27.2.76 RXTXPort.java --- src/gnu/io/RXTXPort.java 13 Nov 2008 23:37:45 -0000 1.27.2.76 +++ src/gnu/io/RXTXPort.java 17 Apr 2009 02:05:48 -0000 @@ -1,7 +1,7 @@ /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. -| Copyright 1997-2008 by Trent Jarvi tjarvi at qbang.org and others who +| Copyright 1997-2009 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at @@ -398,19 +398,16 @@ { if (debug) z.reportln( "RXTXPort:enableReceiveTimeout() called"); - if( time >= 0 ) - { - timeout = time; - NativeEnableReceiveTimeoutThreshold( time , threshold, - InputBuffer ); - } - else + if( time < 0 ) { throw new IllegalArgumentException ( "Unexpected negative timeout value" ); } + timeout = time; + NativeEnableReceiveTimeoutThreshold( timeout , threshold, + InputBuffer ); if (debug) z.reportln( "RXTXPort:enableReceiveTimeout() returning"); } @@ -444,19 +441,16 @@ { if (debug) z.reportln( "RXTXPort:enableReceiveThreshold( " + thresh + " ) called"); - if(thresh >=0) - { - threshold=thresh; - NativeEnableReceiveTimeoutThreshold(timeout, threshold, - InputBuffer); - } - else /* invalid thresh */ + if(thresh < 1) { throw new IllegalArgumentException ( - "Unexpected negative threshold value" + "Threshold value must be possitive" ); } + threshold=thresh; + NativeEnableReceiveTimeoutThreshold(timeout, threshold, + InputBuffer); if (debug) z.reportln( "RXTXPort:enableReceiveThreshold( " + thresh + " ) returned"); } @@ -465,8 +459,12 @@ public void disableReceiveThreshold() { if (debug) - z.reportln( "RXTXPort:disableReceiveThreshold() called and returning"); - enableReceiveThreshold(0); + z.reportln( "RXTXPort:disableReceiveThreshold(0) called"); + threshold = 0; + NativeEnableReceiveTimeoutThreshold(timeout, threshold, + InputBuffer); + if (debug) + z.reportln( "RXTXPort:disableReceiveThreshold(0) returning"); } /** * @return int the recieve threshold @@ -1415,7 +1413,7 @@ */ int Minimum = len; - if( threshold==0 ) + if( threshold < 1 ) { /* * If threshold is disabled, read should return as soon @@ -1528,7 +1526,7 @@ */ int Minimum = len; - if( threshold==0 ) + if( threshold < 1 ) { /* * If threshold is disabled, read should return as soon From cowwoc at bbs.darktech.org Thu Apr 16 23:09:03 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Fri, 17 Apr 2009 01:09:03 -0400 Subject: [Rxtx] Problems with read timeout In-Reply-To: References: <49E64A4A.1050806@bbs.darktech.org> Message-ID: <49E80EEF.6000503@bbs.darktech.org> I've been playing with the read timeout behavior and I'm seeing some non-intuitive behavior. I've got an endless loop that does the following: 1) COM1 and COM2 are connected to one another. They are opened at 300 baud, with read timeout of 300ms. 2) COM1 writes "CONNECTION" 3) COM2 reads "CONNECTION" 4) COM2 writes "CONNECTION 9600 8 NONE 1 RTS/CTS" and tries a read operation. 5) COM1 receives "CONNECTION 960" when suddenly COM2 hits the 300ms read timeout. COM2 gets an IOException (caused by the timeout), and closes the serial port. 6) COM1 never gets the full message because the connection was closed in middle of sending. I want step 4 to block until COM1 receives the full message before it attempts the read operation but I'm not sure how to achieve this. I was somewhat expecting the write() or flush() operation to block until the send was complete... Any ideas? Gili From Steffen.DETTMER at ingenico.com Fri Apr 17 03:55:01 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 17 Apr 2009 11:55:01 +0200 Subject: [Rxtx] Java5 support In-Reply-To: <49E7900D.3060100@bbs.darktech.org> References: <91BF244D-07E4-4B30-9F9D-0DC0964045B4@cometway.com> <49E7900D.3060100@bbs.darktech.org> Message-ID: <20090417095501.GL13774@elberon.bln.de.ingenico.com> Hi, I cannot resist to make some comments, too :) In short, I think rxtx and gnu.io are good. Even if the API is `accidently' the same as javax.comm, logically rxtx IMHO is independent. It offers functionality an application can use - it does not need javax.comm at all. - IMHO Javadoc of javax.comm is /not/ good. What does it help to document `DATABITS_5' with `5 data bit format'? The documentation of SerialPort to me looks like what a less interested, less motivated student would write after failing a code review because of lack of documentation (review of course will fail again, even worse, because identifier <-> microdoc redundancy :)) There are so many issues with the docs... Also, those `optional functionality' is IMHO just a design bug. An interface is to define the interface, the features and functions that are available. Now Java has interfaces with optional functions. loooooooooool This ends that you have an application using this interface correctly and having a correct implementation of this interface but they do not work together because in fact they are using a different interface. It was hidden to the compiler by using `optional methods'. Just great. - namespace gnu.io IMHO is correct (well, don't know if gnu is correct etc, I just mean different from javax is) namespaces are exactly invented for such cases. Maybe gnu.io could implement javax.comm interfaces, maybe not. If someone really has a problem with package names, why not simply perl -npi -e 's/gnu.io/javax.comm/g' *.java could be some rule in some Makefile. - Some `wrapper' adding usability to the Java APIs (like InputStream) IMHO is essential and required anyway. I dislike the APIs, for instance InputStream and those. It is almost impossible to write really correct code with it. It is sufficient for simple GUI stuff you can kill if it blocks or so, but for e.g. server applications IMHO it is not sufficient. Timeouts are needed and so on. Well, this would just lead to a API discussion which would be a different topic. Because a wrapper is needed, package namings IMHO are no issue. Personally, I would prefer for some future version to drop the logical dependency to the stange javax.comm.SerialPort thingy, instead have a clean simple but specific JNI interface. This is `an implementation detail', so rxtx can do whatever is appropriate :) - this java event and multi-threading mixes IMHO often are just a workaround for a missing select(2). On linux, for instance, select and related functions are really strong. You can select in one and the same call a serial port, a TCP socket and a file if you want. In recently it seems Java people started to understand and did some new (not that new, java5 IIRC :)) APIs allowing things like that. They also introduced a new `ByteBuffer' for JNI performance IIRC. Applications using this also are not compatible to javax.comm. Also, the abstraction isn't sufficient IMHO, because applications cannot use InputStream because of missing timeouts, so they must use e.g. SerialPort and now all abstraction is gone, because timeouts for a SerialPort and SocketChannel are completely different in Java (unlike select(), which does abstract). So I think the `break' from javax.comm should be no issue. - rxtx is not required to provide high performance (I think). Of course it should be fast and stable, but IMHO no high performance is needed; typical applications probably just have to work with a few serial ports. When high performance is an issue, I think it would be required that on the JNI interface multiple ports can be processed with a single thread and a single call, for instance if data is buffered per port and the single call processes all active ports or so. In such a case I think it would be likely that a kind of BSD socket API interface would result as internal JNI interface, but this also is another topic. I think 64 port serial console servers are rare today and probably not implemented in Java :-) oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Steffen.DETTMER at ingenico.com Fri Apr 17 04:24:16 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 17 Apr 2009 12:24:16 +0200 Subject: [Rxtx] Problems with read timeout In-Reply-To: <49E80EEF.6000503@bbs.darktech.org> References: <49E64A4A.1050806@bbs.darktech.org> <49E80EEF.6000503@bbs.darktech.org> Message-ID: <20090417102416.GM13774@elberon.bln.de.ingenico.com> Hi, * cowwoc wrote on Fri, Apr 17, 2009 at 01:09 -0400: > I want step 4 to block until COM1 receives the full message before it Do you really want to block? Block means infinite timeout. In case of a serial communication issue (or such) your application will just hang. I think, usually, timeouts are no errors. On timeouts, often it is not correct to close the communication mean where it occured. > attempts the read operation but I'm not sure how to achieve > this. I was somewhat expecting the write() or flush() operation > to block until the send was complete... Any ideas? Typically you cannot know when the send really happend. OS buffers probably many bytes and UART several bits at least. With hardware flow control it might happen that sending a byte takes long time (seconds, minutes or even more). For testing your new implementation maybe you use some other tool (application or hardware, like a modem) to avoid that e.g. receive issues on one side are looking like send issues on the other - or so. Maybe you start some timer for a total timeout and call read in a loop (with the remaining time of the timer as timeout, half of the remaining time limited to a big fixed value or a small fixed value to poll)? When using small timeouts (lets say below 100 ms, not sure if 300 ms could be a problem too), be aware that because of interupt delays, other processes consuming CPU time or whatever reasons an operation can take longer, so a timer is expired but no timeout happend. Sometimes even (debug) log file writing can take so much or even more time. So for a more robust implementation it could help to invoke a read with a very short timeout right after the timer expired. If there is some (internally OS buffered) data it will be returned (this should not considered a timeout, i.e. not throw an exception). oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Kustaa.Nyholm at planmeca.com Fri Apr 17 05:54:50 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 17 Apr 2009 14:54:50 +0300 Subject: [Rxtx] Java5 support In-Reply-To: <9146C76F-17D8-468D-A0F2-CAC9512BCDD6@cometway.com> Message-ID: > From: Paul Cunningham > [snip] in a world where RS-232 is only used for legacy support of devices > with no hope for firmware updates. This is not entirely true. I mean there is a lot more to RS-232 than 'legacy support of devices with no hope for firmware updates'. The alternatives to RS-232 (USB comes to mind) are not that attractive to many niche device / system manufactures because implementing them and supporting them, especially across many platforms is often beyond their means and capabilities. Hence even new designs are based on RS232 on way or the other. RS232 is about the only easy(ish) way to access the outside world from in a relatively device and platform independent manor. Also even when implementing USB is feasible the other limitation of USB may make RS232 much more attractive proposition. Five meter cable length limitation and the utter unpracticality of implementing galvanic isolation come to mind. br Kusti BTW I did not quite get what the rest of the sentence ('with no hope for firmware updates') referred to. From Kustaa.Nyholm at planmeca.com Fri Apr 17 05:56:05 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 17 Apr 2009 14:56:05 +0300 Subject: [Rxtx] FW: Java5 support In-Reply-To: Message-ID: Ooops, sorry Gili, this was meant for the list. > From: Kustaa Nyholm > Date: Fri, 17 Apr 2009 14:41:48 +0300 > To: cowwoc > Conversation: [Rxtx] Java5 support > Subject: Re: [Rxtx] Java5 support > > > Nor Mac support and I think the Linux support is not complete either. > > It is a pity. I'm afraid it reflects the state of desktop Java which is sad > because there really are no alternative to Java for writing rich desktop > applications that look reasonably native on each of the three major platforms > in mostly platform agnostic way. > > br Kusti > >> From: cowwoc >> >> Last time I looked this, there was no usable Windows version. >> >> Gili >> >> Trent Jarvi wrote: >>> Hi Paul, >>> >>> JSR 80 is USB HID support. >>> >>> http://javax-usb.org/ >>> http://jcp.org/aboutJava/communityprocess/final/jsr080/index.html >>> >>> On Thu, 16 Apr 2009, Paul Cunningham wrote: >>> >>>> btw, i mean no disrespect to anyone actively developing an RS-232 >>>> interfaces for new devices. >>>> >>>> in fact my most recent project involved a freescale chip using a UART- >>>> to-USB chip, as i have no idea how to go about interfacing USB devices >>>> to Java. RXTX behaved very well, even when the USB driver didn't. >>>> >>>> is there anything resembling javax.comm for USB? -pc >>>> >>>> >>>> On Apr 16, 2009, at 5:52 PM, Paul Cunningham wrote: >>>> >>>>> in a world where RS-232 is >>>>> only used for legacy support of devices with no hope for firmware >>>>> updates. >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx ------ End of Forwarded Message From Kustaa.Nyholm at planmeca.com Fri Apr 17 05:56:42 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 17 Apr 2009 14:56:42 +0300 Subject: [Rxtx] FW: Java5 support In-Reply-To: Message-ID: Oops again, this was meant for the list. Sorry. ------ Forwarded Message > From: Kustaa Nyholm > Date: Fri, 17 Apr 2009 14:38:36 +0300 > To: Steffen DETTMER > Conversation: [Rxtx] Java5 support > Subject: Re: [Rxtx] Java5 support > >> From: Steffen DETTMER > >> - IMHO Javadoc of javax.comm is /not/ good....[SNIP] > Maybe documentation in javax.comm isnot first class but it is better than no > documentation. > > Having said that I have no desire to get this documentation copied over to > gnu.io I can just as well use the little bits I need from the javadocs of > javax.comm. > > After all this is a very small API and I would very much like it to stay that > way.e in some Makefile. >> >> - Some `wrapper' adding usability to the Java APIs (like >> InputStream) IMHO is essential and required anyway. >> > Me for one definitely don't need anywrapper, I'm happy with the way > the API is. javax.comm/gnu.io is a very low level abstraction of > the under laying hardware, and IMO it should stay that way. Anyone > interested in a better wrapper is of course free to implement and > publish one, if so inclined. But let's keep this in perspective, > serial port is small, but sometimes crucial, well established thing > that will not get better by braking things by improving it. > >> I dislike the APIs, for instance InputStream and those. It is >> almost impossible to write really correct code with it. It is >> sufficient for simple GUI stuff you can kill if it blocks or >> so, but for e.g. server applications IMHO it is not sufficient. >> Timeouts are needed and so on. > Would be fascinating to learn more about this as I've never had > any problem with APIs. > >> >> Well, this would just lead to a API discussion which would be a >> different topic. >> >> Because a wrapper is needed, package namings IMHO are no issue. >> Personally, I would prefer for some future version to drop the >> logical dependency to the stange javax.comm.SerialPort thingy, >> instead have a clean simple but specific JNI interface. >> This is `an implementation detail', so rxtx can do whatever is >> appropriate :) >> > I would suspect that most user would not welcome anything that brakes > compatibility with the existing API. Let's improve something in > a separate wrapper project. >> >> >> - this java event and multi-threading mixes IMHO often are just a >> workaround for a missing select(2). On linux, for instance, >> select and related functions are really strong. You can select >> in one and the same call a serial port, a TCP socket and a file >> if you want. In recently it seems Java people started to >> understand and did some new (not that new, java5 IIRC :)) APIs >> allowing things like that. They also introduced a new >> `ByteBuffer' for JNI performance IIRC. >> >> Applications using this also are not compatible to javax.comm. >> Also, the abstraction isn't sufficient IMHO, because >> applications cannot use InputStream because of missing >> timeouts, so they must use e.g. SerialPort and now all >> abstraction is gone, because timeouts for a SerialPort and >> SocketChannel are completely different in Java (unlike >> select(), which does abstract). > I'm not sure I followed/understood everything above but it smelt > like *one* POV and I suspect, that if I had understood what I read, that > I would have had a different POV. >> >> So I think the `break' from javax.comm should be no issue. > Depending on what above means this could be huge issues for many of us. > But I think I've said that several times already. >> >> >> >> - rxtx is not required to provide high performance (I think). > Agree. >> >> Of course it should be fast and stable, but IMHO no high >> performance is needed; typical applications probably just have >> to work with a few serial ports. > Agree. >> >> When high performance is an issue, I think it would be required >> that on the JNI interface multiple ports can be processed with >> a single thread and a single call, for instance if data is >> buffered per port and the single call processes all active >> ports or so. In such a case I think it would be likely that a >> kind of BSD socket API interface would result as internal JNI >> interface, but this also is another topic. > This paragraph had so many assumptions that I refrain from commenting > other than that it portrays one POV which again I suspect I do not > care for. >> >> I think 64 port serial console servers are rare today and >> probably not implemented in Java :-) >> >> >> oki, >> >> Steffen >> > br Kusti ------ End of Forwarded Message From Kustaa.Nyholm at planmeca.com Fri Apr 17 06:01:15 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 17 Apr 2009 15:01:15 +0300 Subject: [Rxtx] rxtx list configuration... Message-ID: Trent, Would it be possible to configure the mail headers for mail that comes from the list so that the 'from' field would be 'rxtx at qbang.org' and not the posters email address? That would save me a couple of clicks each time I reply (now I need to 'reply to all' and delete the other recipients) and a few mistakes (when I hit the 'reply to sender'). Just did that mistake twice in a row, my apologies for those concerned. Just a wish. br Kusti From ilkka at myller.com Fri Apr 17 06:17:14 2009 From: ilkka at myller.com (Ilkka Myller) Date: Fri, 17 Apr 2009 15:17:14 +0300 Subject: [Rxtx] Java5 support In-Reply-To: References: Message-ID: <934E311F-9FCC-4EF2-A1D5-960285363221@myller.com> I completely agree with Kustaa on this one. Our company is developing devices with embedded hardware. We are using RS-232 (and other serial interfaces) with both old and new designs. Serial interfaces are convenient/practical with embedded low cost microprocessors etc. where hardware/software overhead and complexity of more "modern" interfaces is just .. well.. overhead. So, in my opinion, RS-232 (and others) are not obsolete or legacy - at least in industrial/embedded development. It is true, that there are little or no new consumer devices with RS-232 interfaces. -- I >> From: Paul Cunningham >> [snip] in a world where RS-232 is only used for legacy support of >> devices >> with no hope for firmware updates. > > This is not entirely true. I mean there is a lot more to RS-232 than > 'legacy > support of devices with no hope for firmware updates'. > > The alternatives to RS-232 (USB comes to mind) are not that > attractive to > many niche device / system manufactures because implementing them and > supporting them, especially across many platforms is often beyond > their > means and capabilities. Hence even new designs are based on RS232 on > way > or the other. > > RS232 is about the only easy(ish) way to access the outside world > from in a > relatively device and platform independent manor. > > Also even when implementing USB is feasible the other limitation of > USB may > make RS232 much more attractive proposition. Five meter cable length > limitation and the utter unpracticality of implementing galvanic > isolation > come to mind. > > br Kusti > > BTW I did not quite get what the rest of the sentence ('with no hope > for > firmware updates') referred to. > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From cowwoc at bbs.darktech.org Fri Apr 17 06:48:31 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Fri, 17 Apr 2009 08:48:31 -0400 Subject: [Rxtx] Problems with read timeout In-Reply-To: <49E80EEF.6000503@bbs.darktech.org> References: <49E64A4A.1050806@bbs.darktech.org> <49E80EEF.6000503@bbs.darktech.org> Message-ID: <49E87A9F.9070200@bbs.darktech.org> To be clear, I'm not really sure I want write() to block. I just want a way to get a timeout if no data has been read or written in at least X ms (i.e. we're waiting on the remote end) *and* we're blocked on a read() or write() command. It's not clear to me how to achieve this, with or without the new NIO APIs. I'm fairly certain the only way this will work is if flush() blocks until the remote end receives the full message. I'll look into the C code later on tonight to see if this is possible. What are your thoughts on this? Gili cowwoc wrote: > > I've been playing with the read timeout behavior and I'm seeing some > non-intuitive behavior. > > I've got an endless loop that does the following: > > 1) COM1 and COM2 are connected to one another. They are opened at 300 > baud, with read timeout of 300ms. > 2) COM1 writes "CONNECTION" > 3) COM2 reads "CONNECTION" > 4) COM2 writes "CONNECTION 9600 8 NONE 1 RTS/CTS" and tries a read > operation. > 5) COM1 receives "CONNECTION 960" when suddenly COM2 hits the 300ms read > timeout. COM2 gets an IOException (caused by the timeout), and closes > the serial port. > 6) COM1 never gets the full message because the connection was closed in > middle of sending. > > I want step 4 to block until COM1 receives the full message before > it attempts the read operation but I'm not sure how to achieve this. I > was somewhat expecting the write() or flush() operation to block until > the send was complete... Any ideas? > > Gili > From paul at cometway.com Fri Apr 17 08:23:18 2009 From: paul at cometway.com (Paul Cunningham) Date: Fri, 17 Apr 2009 10:23:18 -0400 Subject: [Rxtx] Java5 support In-Reply-To: References: Message-ID: <91A48B92-4A0D-4030-9129-F0657723765B@cometway.com> >> From: Paul Cunningham >> [snip] in a world where RS-232 is only used for legacy support of >> devices >> with no hope for firmware updates. > > This is not entirely true. I mean there is a lot more to RS-232 than > 'legacy > support of devices with no hope for firmware updates'. Hi Kustaa -- Oh I agree with you, mostly. Read my other post. Its just that the money isn't really there to commercially push RS-232 as a mainstream solution anymore. It's difficult these days to find a computer with a DB9 port for doing RS-232 stuff. Anyone still making that kind of hardware is seriously industrial or fringe/hobbyist. On Apr 17, 2009, at 7:54 AM, Kustaa Nyholm wrote: > BTW I did not quite get what the rest of the sentence ('with no hope > for > firmware updates') referred to. Hobbyists are always interested in finding new uses for uniquely functional serial devices that are no longer made, supported, and/or documented. While reverse engineering can be fun, sometimes bad serial driver code and protocol anomalies make it less than straight-forward to implement a reliable interface, and it's not because RXTX isn't working correctly. I have a cool little device that we use to monitor the temperature of our server room using RXTX, but the code I had to write to get it working was less than conventional. -pc -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090417/61103c37/attachment-0003.html From tjarvi at qbang.org Fri Apr 17 08:34:13 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 17 Apr 2009 08:34:13 -0600 (MDT) Subject: [Rxtx] Problems with read timeout In-Reply-To: <49E87A9F.9070200@bbs.darktech.org> References: <49E64A4A.1050806@bbs.darktech.org> <49E80EEF.6000503@bbs.darktech.org> <49E87A9F.9070200@bbs.darktech.org> Message-ID: The bytesavailable event can be used to start your read. There is also an outputbufferempty event. On Fri, 17 Apr 2009, cowwoc wrote: > > To be clear, I'm not really sure I want write() to block. I just want a > way to get a timeout if no data has been read or written in at least X > ms (i.e. we're waiting on the remote end) *and* we're blocked on a > read() or write() command. > > It's not clear to me how to achieve this, with or without the new NIO > APIs. I'm fairly certain the only way this will work is if flush() > blocks until the remote end receives the full message. I'll look into > the C code later on tonight to see if this is possible. What are your > thoughts on this? > > Gili > > cowwoc wrote: >> >> I've been playing with the read timeout behavior and I'm seeing some >> non-intuitive behavior. >> >> I've got an endless loop that does the following: >> >> 1) COM1 and COM2 are connected to one another. They are opened at 300 >> baud, with read timeout of 300ms. >> 2) COM1 writes "CONNECTION" >> 3) COM2 reads "CONNECTION" >> 4) COM2 writes "CONNECTION 9600 8 NONE 1 RTS/CTS" and tries a read >> operation. >> 5) COM1 receives "CONNECTION 960" when suddenly COM2 hits the 300ms read >> timeout. COM2 gets an IOException (caused by the timeout), and closes >> the serial port. >> 6) COM1 never gets the full message because the connection was closed in >> middle of sending. >> >> I want step 4 to block until COM1 receives the full message before >> it attempts the read operation but I'm not sure how to achieve this. I >> was somewhat expecting the write() or flush() operation to block until >> the send was complete... Any ideas? >> >> Gili >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Steffen.DETTMER at ingenico.com Fri Apr 17 09:17:51 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 17 Apr 2009 17:17:51 +0200 Subject: [Rxtx] FW: Java5 support In-Reply-To: References: Message-ID: <20090417151751.GD16563@elberon.bln.de.ingenico.com> * Kustaa Nyholm wrote on Fri, Apr 17, 2009 at 14:56 +0300: > > - Some `wrapper' adding usability to the Java APIs (like > > InputStream) IMHO is essential and required anyway. > > > Me for one definitely don't need anywrapper, I'm happy with the way > the API is. javax.comm/gnu.io is a very low level abstraction of > the under laying hardware, and IMO it should stay that way. Well, so it seems it is a matter of opinion (for me, it is neither an abstraction nor low level; actually, InputStream IMHO is a high [too high] level). (I also think it should stay the way as it is, which IMHO is gnu.io not javax.comm) > Anyone interested in a better wrapper is of course free to > implement and publish one, if so inclined. But let's keep this > in perspective, serial port is small, but sometimes crucial, > well established thing that will not get better by braking > things by improving it. Is the SerialPort API a `well established thing'? I would consider it exotic - most people / applications never used it, I guess. > > I dislike the APIs, for instance InputStream and those. It is > > almost impossible to write really correct code with it. It is > > sufficient for simple GUI stuff you can kill if it blocks or > > so, but for e.g. server applications IMHO it is not sufficient. > > Timeouts are needed and so on. > > Would be fascinating to learn more about this as I've never had > any problem with APIs. Does this mean you are using InputStream for communication and you never had any problem with it? Including no timeout related problems appeared? We had and have a lot here. Sometimes timeouts are not precise enough and synchronisation with embedded stuff fails. Issues with serial w/o (hardware/any) flow control and performance. Issues with lower performance because of unprecise polling timeouts. To big timeouts leading to slow systems and to small timeouts to leading to trouble to unwanted repeations or messages where message boundaries depend on timeouts (like X.25 Gateways without ADPU protocols). I think the most troublesome things here are those transparent protocol converters / gateways and the protocols that depend on timeouts (like `100 ms silence for block separation' or `optional CRC within X.25 frame timeout or set more bit' converted to serial line). If you're using some PPP with TCP on top, I guess this wouldn't be critical because TCP cares about timeouts and retransmissions, but on serial links we often have to implement various protocols without such features. I think, with just an InputStream / OutputStream API it would be almost impossible to write a good, stable and performant TCP/IP/PPP stack. > > Well, this would just lead to a API discussion which would be a > > different topic. > > > > Because a wrapper is needed, package namings IMHO are no issue. > > Personally, I would prefer for some future version to drop the > > logical dependency to the stange javax.comm.SerialPort thingy, > > instead have a clean simple but specific JNI interface. > > This is `an implementation detail', so rxtx can do whatever is > > appropriate :) > > > I would suspect that most user would not welcome anything that > brakes compatibility with the existing API. I would not be surprised if more use gnu.io than javax.comm, so also because of this it would be gnu.io that rxtx should be compatible to! (actually this is a guess, maybe someone has some statistics or makes some poll? I vote for gnu.io and would be able to find more inside the company :)) The JNI interface isn't to be used by the applications; they should work on gnu.io.SerialPort and related objects but never directly on all the JNI functions. >> timeouts, so they must use e.g. SerialPort and now all >> abstraction is gone, because timeouts for a SerialPort and >> SocketChannel are completely different in Java (unlike >> select(), which does abstract). >> > I'm not sure I followed/understood everything above but it > smelt like *one* POV and I suspect, that if I had understood > what I read, that I would have had a different POV. yeah, maybe... (but maybe BSD socket API style is just strong and InputStream API style is just weak - and that recent Java APIs come closer to BSD socket API style IMHO could be an indication that others agree). >> So I think the `break' from javax.comm should be no issue. > Depending on what above means this could be huge issues for > many of us. But I think I've said that several times already. well, I thought almost noone is still using javax.comm, thought only gnu.io was maintained and bugfixed since quite some time (years) - even if technically it is implemented in a branch 0.1.0. This branch IMHO is also an implementation detail; I think (not sure, of course I can be wrong, let's ask Trent and the team). I think rxtx users should not care from which branch a release is built. > > When high performance is an issue, I think it would be required > > that on the JNI interface multiple ports can be processed with > > a single thread and a single call, for instance if data is > > buffered per port and the single call processes all active > > ports or so. In such a case I think it would be likely that a > > kind of BSD socket API interface would result as internal JNI > > interface, but this also is another topic. > > > This paragraph had so many assumptions that I refrain from > commenting other than that it portrays one POV which again I > suspect I do not care for. An alternative, which could be more helpful than refraining from commenting :-), could be to add other high performance setups that could exist on PCs (or where rxtx is running one). anyway, we agree that no ultra high performance requirements exist (probably). I admit that I accidently focussed on UART style hardware for 115kbaud or so, where one port is easy to handle. Yes, of course you are right, there could be a high performance requirement even for setups with few ports, even with a single one. Do you have an example of it which is not very specific (and thus wants to use rxtx)? IMHO it does not help much to talk about specific special serial power hardware which may even require to be accessed with specific driver APIs, because this is out of scope of rxtx :-) oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Steffen.DETTMER at ingenico.com Fri Apr 17 09:40:07 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 17 Apr 2009 17:40:07 +0200 Subject: [Rxtx] Java5 support In-Reply-To: <91A48B92-4A0D-4030-9129-F0657723765B@cometway.com> References: <91A48B92-4A0D-4030-9129-F0657723765B@cometway.com> Message-ID: <20090417154006.GE16563@elberon.bln.de.ingenico.com> * Paul Cunningham wrote on Fri, Apr 17, 2009 at 10:23 -0400: > > This is not entirely true. I mean there is a lot more to > > RS-232 than 'legacy support of devices with no hope for > > firmware updates'. > > Hi Kustaa -- Oh I agree with you, mostly. Read my other post. > Its just that the money isn't really there to commercially > push RS-232 as a mainstream solution anymore. this depends where you look. On a rxtx mailing list, RS-232 surely is mainstream - guess everyone here is using it :-) Network routers usually still have a serial console and embedded board often have one (which probably counts as industrial). > It's difficult these days to find a computer with a DB9 port > for doing RS-232 stuff. Anyone still making that kind of > hardware is seriously industrial or fringe/hobbyist. Yes, consumer devices are rarely with RS232 now, but have USB (or bluetooth). But on PC, you usually can plug some PCMCIA / PCI card or a USB interface to connect, which sometimes also have their issues... Maybe would be interesting to see what people are using rxtx and RS232 here for? The temperature monitor is nice :) I could imagine a few other similar things people use here (connecting to some small controller/sensor board or so). We use it to communicate with various embedded devices, cash registers, small serial printers and communication means like modems and pads (mostly in C but some in Java). oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Steffen.DETTMER at ingenico.com Fri Apr 17 09:51:56 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 17 Apr 2009 17:51:56 +0200 Subject: [Rxtx] rxtx list configuration... In-Reply-To: References: Message-ID: <20090417155156.GF16563@elberon.bln.de.ingenico.com> [OT] * Kustaa Nyholm wrote on Fri, Apr 17, 2009 at 15:01 +0300: > Would it be possible to configure the mail headers for mail > that comes from the list so that the 'from' field would be > 'rxtx at qbang.org' and not the posters email address? Please don't rewrite the `From:' field, because then it would not visible who wrote a posting and it would violate standards potentionally leading to all sort of problems. > That would save me a couple of clicks each time I reply (now I > need to 'reply to all' and delete the other recipients) and a > few mistakes (when I hit the 'reply to sender'). There are mail programs (MUAs) and Plug-Ins for others that handle this automatically. > Just did that mistake twice in a row, my apologies for those concerned. no problem (other way around would be bad :)). oki, Steffen BTW: http://www.unicom.com/pw/reply-to-harmful.html http://woozle.org/~neale/papers/reply-to-still-harmful.html> About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Steffen.DETTMER at ingenico.com Fri Apr 17 09:54:50 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 17 Apr 2009 17:54:50 +0200 Subject: [Rxtx] Java5 support In-Reply-To: <20090417154006.GE16563@elberon.bln.de.ingenico.com> References: <91A48B92-4A0D-4030-9129-F0657723765B@cometway.com> <20090417154006.GE16563@elberon.bln.de.ingenico.com> Message-ID: <20090417155450.GG16563@elberon.bln.de.ingenico.com> * Steffen Dettmer wrote on Fri, Apr 17, 2009 at 17:40 +0200: > Maybe would be interesting to see what people are using rxtx and > RS232 here for? http://rxtx.qbang.org/wiki/index.php/Projects is impressing. oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From bschlining at gmail.com Fri Apr 17 10:25:52 2009 From: bschlining at gmail.com (Brian Schlining) Date: Fri, 17 Apr 2009 09:25:52 -0700 Subject: [Rxtx] Java5 support In-Reply-To: <20090417154006.GE16563@elberon.bln.de.ingenico.com> References: <91A48B92-4A0D-4030-9129-F0657723765B@cometway.com> <20090417154006.GE16563@elberon.bln.de.ingenico.com> Message-ID: > > Maybe would be interesting to see what people are using rxtx and > RS232 here for? The vast majority of oceanographic instruments that we work with have serial connectors. These include acoustic doppler current profilers (ADCP), conductivity-temperature-depth sensors (CTD), radiometers, oxygen sensors, and meteorology sensors. We also use pro-grade VCR's that have serial ports on them for control. We use RXTX on a range of JVM's from J9 through the latest Sun JVM. A particularly cool project that we use RXTX for is SIAM ( http://www.mbari.org/moos/siam/siam.htm). Especially note the PUCK protocol (http://www.mbari.org/pw/puck.htm). Essentially, we create instruments with a little blob of Java code embedded with it as the instrument driver. When the instrument gets plugged in the host controller grabs the driver off and starts running it. Voila, plug-and-work instruments (almost always controlled via a serial port using RXTX) -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090417/f92c3bf8/attachment-0003.html From cowwoc at bbs.darktech.org Fri Apr 17 10:50:15 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Fri, 17 Apr 2009 12:50:15 -0400 Subject: [Rxtx] Java5 support In-Reply-To: <20090417095501.GL13774@elberon.bln.de.ingenico.com> References: <91BF244D-07E4-4B30-9F9D-0DC0964045B4@cometway.com> <49E7900D.3060100@bbs.darktech.org> <20090417095501.GL13774@elberon.bln.de.ingenico.com> Message-ID: <49E8B347.9010609@bbs.darktech.org> I wanted to address two points that have been brought up: > New development doesn't use RS-232. Actually, I've seen quite a few devices using RS-232 over USB. > InputStream isn't appropriate for RS-232 because of timeouts. This is addressed by java.nio.Channels. Gili From greg.johnson at rbr-global.com Fri Apr 17 10:51:44 2009 From: greg.johnson at rbr-global.com (Greg Johnson) Date: Fri, 17 Apr 2009 12:51:44 -0400 Subject: [Rxtx] Java5 support In-Reply-To: References: <91A48B92-4A0D-4030-9129-F0657723765B@cometway.com> <20090417154006.GE16563@elberon.bln.de.ingenico.com> Message-ID: <42447237-7898-470E-835B-A09A6119458F@rbr-global.com> And we make some of those oceanographic instruments - and we use RXTX to configure and download data from them... We run our code on win32/ osx/linux (x86) and the Aonix Perc Ultra JVM (arm). (Brian, please say hi to Tom O'R. for me - I didn't realise mbari was represented on this list :) Cheers, greg -- Greg Johnson, PhD Director of Engineering http://www.rbr-global.com greg.johnson at rbr-global.com +1.613.233.1621 (GMT-5) office +1.613.986.1621 (GMT-5) mobile See us at: Oceans '09 IEEE, Bremen, Germany, May 11 - 14, 2009 On 17-Apr-09, at 12:25 , Brian Schlining wrote: > Maybe would be interesting to see what people are using rxtx and > RS232 here for? > > The vast majority of oceanographic instruments that we work with > have serial connectors. These include acoustic doppler current > profilers (ADCP), conductivity-temperature-depth sensors (CTD), > radiometers, oxygen sensors, and meteorology sensors. We also use > pro-grade VCR's that have serial ports on them for control. We use > RXTX on a range of JVM's from J9 through the latest Sun JVM. > > A particularly cool project that we use RXTX for is SIAM (http://www.mbari.org/moos/siam/siam.htm > ). Especially note the PUCK protocol (http://www.mbari.org/pw/ > puck.htm). Essentially, we create instruments with a little blob of > Java code embedded with it as the instrument driver. When the > instrument gets plugged in the host controller grabs the driver off > and starts running it. Voila, plug-and-work instruments (almost > always controlled via a serial port using RXTX) > > -- > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > Brian Schlining > bschlining at gmail.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090417/d2048c45/attachment-0003.html From tjarvi at qbang.org Fri Apr 17 11:16:45 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 17 Apr 2009 11:16:45 -0600 (MDT) Subject: [Rxtx] Java5 support In-Reply-To: <42447237-7898-470E-835B-A09A6119458F@rbr-global.com> References: <91A48B92-4A0D-4030-9129-F0657723765B@cometway.com> <20090417154006.GE16563@elberon.bln.de.ingenico.com> <42447237-7898-470E-835B-A09A6119458F@rbr-global.com> Message-ID: Disclosure on my part. rxtx is used in the base MATLAB product with an estimated 4 million usrs. http://www.informaworld.com/smpp/title~content=t795248263~db=all http://www.mathworks.com/products/instrument/supportedio13781.html We see some funky projects :) USB serial dongle drivers improving over the last few years has actually boosted the popluarity of serial use. On Fri, 17 Apr 2009, Greg Johnson wrote: > And we make some of those oceanographic instruments - and we use RXTX to > configure and download data from them... ?We run our code on win32/osx/linux > (x86) and the Aonix Perc Ultra JVM (arm). > (Brian, please say hi to Tom O'R. for me - I didn't realise mbari was > represented on this list :) > > Cheers, > > greg > > -- > Greg Johnson, PhD > Director of Engineering > http://www.rbr-global.com > greg.johnson at rbr-global.com > +1.613.233.1621 (GMT-5) office > +1.613.986.1621 (GMT-5) mobile > > See us at: Oceans '09 IEEE, Bremen, Germany, ?May 11 - 14, 2009 > > > On 17-Apr-09, at 12:25 , Brian Schlining wrote: > > Maybe would be interesting to see what people are > using rxtx and > RS232 here for? > > > The vast majority of?oceanographic?instruments that we work with have > serial connectors. These include acoustic doppler current profilers > (ADCP), conductivity-temperature-depth sensors (CTD), radiometers, > oxygen sensors, and?meteorology?sensors. We also use pro-grade VCR's > that have serial ports on them for control. We use RXTX on a range of > JVM's from J9 through the latest Sun JVM. > > A particularly cool project that we use RXTX for is SIAM > (http://www.mbari.org/moos/siam/siam.htm). Especially note the PUCK > protocol (http://www.mbari.org/pw/puck.htm).?Essentially, we create > instruments with a little blob of Java code embedded with it as the > instrument driver. When the instrument gets plugged in the host > controller grabs the driver off and starts running it. Voila, > plug-and-work instruments (almost always controlled via a serial port > using RXTX) > > -- > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > Brian Schlining > bschlining at gmail.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > From Bob_Jacobsen at lbl.gov Fri Apr 17 18:19:16 2009 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Fri, 17 Apr 2009 17:19:16 -0700 Subject: [Rxtx] Java5 support In-Reply-To: <20090417155450.GG16563@elberon.bln.de.ingenico.com> References: <91A48B92-4A0D-4030-9129-F0657723765B@cometway.com> <20090417154006.GE16563@elberon.bln.de.ingenico.com> <20090417155450.GG16563@elberon.bln.de.ingenico.com> Message-ID: RXTX is not just RS232. A _lot_ of USB equipment provide a serial-port-like interface, e.g. via virtual com port drivers. For a device manufacturer, dropping an FTDI or SiLabs chip into their device to provide a computer interface solves a lot of problems. The chips come with drivers for N varients of Windows, Linux, Mac, etc, so the device manufacturer doesn't have to deal with the computer access issues at all. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From scldad at sdc.com.au Fri Apr 17 19:22:04 2009 From: scldad at sdc.com.au (Stephen Davies) Date: Sat, 18 Apr 2009 10:52:04 +0930 Subject: [Rxtx] Java5 support In-Reply-To: <20090417154006.GE16563@elberon.bln.de.ingenico.com> References: <91A48B92-4A0D-4030-9129-F0657723765B@cometway.com> <20090417154006.GE16563@elberon.bln.de.ingenico.com> Message-ID: <200904181052.04460.scldad@sdc.com.au> We use rxtx to interface to a wide variety of remote sensors located in paddocks around the country. The sensors and controlling loggers are manufactured by Campbell Scientific and the loggers have "real" RS232 interfaces. Cheers, Stephen On Saturday 18 April 2009 01:10:07 Steffen DETTMER wrote: > Maybe would be interesting to see what people are using rxtx and > RS232 here for? -- ============================================================================= Stephen Davies Consulting P/L Voice: 08-8177 1595 Adelaide, South Australia. Fax : 08-8177 0133 Computing & Network solutions. Mobile:040 304 0583 VoIP:sip:1132210 at sip1.bbpglobal.com From johnco3 at gmail.com Sat Apr 18 14:39:01 2009 From: johnco3 at gmail.com (John Coffey) Date: Sat, 18 Apr 2009 16:39:01 -0400 Subject: [Rxtx] Serial Port Hangs with 8K buffers - fix included Message-ID: Trent, it would be great if you could forward this suggestion/fix to the users group. There is API in the javax.comm (or gnu.io) as far as I am aware to set the 'wierd science' parameters that fall outside the rather narrow scope laid out in the framework by sun. The most natural fit would appear to be in the setSerialPortParams. Perhaps if some negative value for the baud rate were specified the interpretaton could be opened up for other things. The only restriction is that the serial port cannot be open at the time this is called (this is not a change) John - Hide quoted text - On Thu, Apr 16, 2009 at 2:17 AM, Trent Jarvi wrote: Hi John, Would you mind if I forward this to the rxtx maillist for review? This falls under the 'weird science' group of things rxtx likes to do but isn't exactly in the API. Also, could go into a little more detail in the following? You don't want to break the API but you need to set that bit? "however I know we cannot violate suns interface definitions there" On Thu, 16 Apr 2009, John Coffey wrote: Trent, I see that RXTX 2.2 is nearing completion. I was happy to see that the non standard baud multiplier fixes made it into the latest qbang as I was previously maintaining a patched 2.1.7 version for my application. I needed to make the following fix to your termios.c native C wrapper in RxTx (both 2.1.7 and more recently 2.2 - pre1) as I don't know a way of specifying the input and output queue sizes after the comm port has been configured and opened by java. My application is a bidirectional application that works file when the block sizes are 2K however, the next step in my protocol is a jump to 8K (actually 8200 bytes) and the data gets stuck approx 2k into the transfer - anyway to fix this I made the default buffer sizes 8200 as you can see below. Can you perhaps think of some way of doing this better as I have 8 serial ports opened and they don't all require 16k's worth of serial io buffering. Perhaps the best way is via the SerialPort.setSerialPortParams native interface to the DLL however I know we cannot violate suns interface definitions there. With the hard coded change to the existing hack bwlow, I have it working very reliably now - although on windows x64, I still have the problem since I dont have a 64 bit compiler for windows. Hope this is useful if( !SetupComm( port->hComm, 2048, 1024 ) ) // @JC allocate an 8K RX and TX buffers associated with the // serial channel, this is for large block support to fix // a hangup in the virtual serial port driver for XP if( !SetupComm( port->hComm, 8200, 8200) ) { YACK(); return -1; } John Coffey -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090418/7784195b/attachment-0001.html From sunil at saltriver.com Mon Apr 20 04:48:10 2009 From: sunil at saltriver.com (Sunil Bhambani) Date: Mon, 20 Apr 2009 16:18:10 +0530 Subject: [Rxtx] RxTx on Mac for USB In-Reply-To: References: <1080422816.3127.6.camel@localhost.localdomain> <1080505612.2924.9.camel@localhost.localdomain> Message-ID: <1240224490.2975.17.camel@localhost.localdomain> Hi All, Bob, I have new GPS device and that device is detected on Mac. Now the problem is that every time I try to open the port it gives exception of PortInUseException. I have tried restarting the system but that doesn't solve the problem. It will always says that Port in Use. I have tried the same code on Windows with the same device and it runs fine. Can someone let me know what may be the problem? Hope to get the response quickly. On Wed, 2009-04-15 at 02:43 -0700, Bob Jacobsen wrote: > At 1:56 AM +0530 3/29/04, Sunil Bhambani wrote: > > > >I am using Mac 10.5 and I have done what you have said. I get the > >following output > > > >total 4 > >crw--w---- 1 Saltriver tty 16, 0 Apr 15 11:13 ttys000 > >crw-rw-rw- 1 root wheel 8, 0 Apr 15 11:13 random > >crw-rw-rw- 1 root tty 15, 1 Apr 15 11:13 ptmx > >crw------- 1 Saltriver staff 0, 0 Apr 15 11:10 console > > ... > > >saltriver-infosystemss-mac-mini:~ Saltriver$ ls -lt /dev/ | head -10 > >total 4 > >crw--w---- 1 Saltriver tty 16, 0 Apr 15 11:16 ttys000 > >crw-rw-rw- 1 root tty 15, 1 Apr 15 11:16 ptmx > >crw-rw-rw- 1 root wheel 8, 0 Apr 15 11:13 random > >crw------- 1 Saltriver staff 0, 0 Apr 15 11:10 console > > ... > > >I think the output is same in both. Is there any way of mounting that device. > > You're going to need a driver of some sort that will make the GPS > unit appear as a serial device. > > > I am very new to Mac. I am using RXTX 2.1 without javax.comm package. > > This problem is happening before RXTX can do anything at all. Unless > there's a device in /dev, RXTX can't even begin to be involved. > > Bob -- Thank & Regards Sunil -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090420/117260bc/attachment.html From michael.erskine at ketech.com Mon Apr 20 06:09:18 2009 From: michael.erskine at ketech.com (Michael Erskine) Date: Mon, 20 Apr 2009 13:09:18 +0100 Subject: [Rxtx] Java5 support In-Reply-To: <20090417154006.GE16563@elberon.bln.de.ingenico.com> References: <91A48B92-4A0D-4030-9129-F0657723765B@cometway.com> <20090417154006.GE16563@elberon.bln.de.ingenico.com> Message-ID: <06BA3262D918014F9183B66425D5A8D45FA42D9203@no-sv-03.ketech.local> > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Steffen DETTMER > Sent: 17 April 2009 16:40 > To: rxtx at qbang.org > Subject: Re: [Rxtx] Java5 support > Maybe would be interesting to see what people are using rxtx and > RS232 here for? We (http://www.ketech.com/) use RXTX on a number of projects: Customer Information Systems on the UK rail network, some London Underground projects, some UK defence projects. I'm not at liberty to discuss them but suffice to say RXTX is our general means for Java serial interfacing and serial test applications. Regards, Michael Erskine. From cowwoc at bbs.darktech.org Wed Apr 1 22:05:13 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Thu, 02 Apr 2009 00:05:13 -0400 Subject: [Rxtx] Windows 64-bit support? Message-ID: <49D43979.4050702@bbs.darktech.org> Hi, I'd like to run RXTX under the Windows 64-bit JVM. Are there plans to release an official 64-bit version anytime soon? Gili From bill7007 at gmail.com Thu Apr 2 16:01:17 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Thu, 2 Apr 2009 18:01:17 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel Message-ID: Hi, I have an rxtx serial application that used to work reliably until I had to move it to newer hardware and kernel. Now, the application sometimes hangs near first port use. When it does hang, it can be released by starting a second copy of the application which is locked out of the ports but does release the first process. Upgraded from rxtx-2.1-7-r2 to rxtx-2.2pre2 but still hangs. Tried to rebuild on the target machine and ran into the 'UTS_RELEASE' undeclared problem so holding on that approach. Recompiled OK on a 2.6.9-42.0.3.ELsmp system. Debug messages were turned on using: "./configure --enable-DEBUG" and modified RXTXPort.java with: "debug = true;" "z = new Zystem(Zystem.PRINT_MODE);" Below is capture of the application with debugging enabled. It show the application hang point, and the second application's printout at the release point. (pre3 is the locally modified version of pre2) Any suggestions on how to pin this down further? Thanks, +BillJ $ java -version java version "1.5.0_06" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05) Java HotSpot(TM) Client VM (build 1.5.0_06-b05, mixed mode, sharing) $ uname -a Linux qms4 2.6.18-92.1.6.el5 #1 SMP Wed Jun 25 13:49:24 EDT 2008 i686 i686 i386 GNU/Linux ***CAPTURE: [qms at qms4 ~]$ ./qms/ScriptFiles/startup.sh Thu Apr 02 13:35:45 EDT 2009:Setting Log File to:/home/qms/qms/QMS.log Thu Apr 02 13:35:45 EDT 2009:TSettings.HandleIni:ReUsing Ini file:/home/qms/qms/qms.properties WARNING: RXTX Version mismatch Jar version = RXTX-2.2pre2 native lib Version = RXTX-2.2pre3 fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB2 fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB1 fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB0 fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10127 fhs_unlock: Removing LockFile RXTXPort {} RXTX WARNING: This library was compiled to run with OS release 2.4.20 and you are currently running OS release 2.6.18-92.1.6.el5. In some cases this can be a problem. Try recompiling RXTX if you notice strange behavior. If you just compiled RXTX make sure /usr/include/linux is a symbolic link to the include files that came with the kernel source and not an older copy. press enter to continue RXTXPort:RXTXPort(/dev/ttyUSB2) called fhs_lock: creating lockfile: 10127 open: locking worked for /dev/ttyUSB2 open: fd returned is 8 RXTXPort:MontitorThread:MonitorThread() RXTXPort:MontitorThread:run() has_line_status_register_acess: Port does not support TIOCSERGETLSR init_threads: get eis init_threads: set eis init_threads: stop RXTXPort:RXTXPort(/dev/ttyUSB2) returns with fd = 8 RXTXPort:setSerialPortParams(38400 8 1 0) called RXTXPort:setSerialPortParams(38400 8 1 0) returning RXTXPort:getInputStream() called and returning Thu Apr 02 13:36:02 EDT 2009:TSerial[22]:Using Port:/dev/ttyUSB2 RXTXPort:getOutputStream() called and returning Thu Apr 02 13:36:02 EDT 2009:TSerial[22].Transmit:TN Entering RXTXPort:SerialOutputStream:write(4) writeArray() Leaving RXTXPort:SerialOutputStream:write(4) RXTXPort:SerialOutputStream:flush() enter RXTXPort:SerialOutputStream:flush() leave Thu Apr 02 13:36:02 EDT 2009:TSerial[22].Transmit:RV Entering RXTXPort:SerialOutputStream:write(4) writeArray() Leaving RXTXPort:SerialOutputStream:write(4) RXTXPort:SerialOutputStream:flush() enter RXTXPort:SerialInputStream:read(8192 0 8192) called ***FIRST PROCESS HANGS HERE ***THEN PROCEEDS AFTER SECOND PROCESS STARTS RXTXPort:SerialOutputStream:flush() leave Thu Apr 02 13:41:29 EDT 2009:TSerial[22].Transmit:IH9 Entering RXTXPort:SerialOutputStream:write(5) writeArray() Leaving RXTXPort:SerialOutputStream:write(5) RXTXPort:SerialOutputStream:flush() enter RXTXPort:SerialOutputStream:flush() leave Thu Apr 02 13:41:29 EDT 2009:TSerial[22].Transmit:IL11 ***END CAPTURE ***CAPTURE SECOND PROCESS FAILS OPEN [qms at qms4 ~]$ ./qms/ScriptFiles/startup.sh Thu Apr 02 13:41:27 EDT 2009:Setting Log File to:/home/qms/qms/QMS.log Thu Apr 02 13:41:27 EDT 2009:TSettings.HandleIni:ReUsing Ini file:/home/qms/qms/qms.properties WARNING: RXTX Version mismatch Jar version = RXTX-2.2pre2 native lib Version = RXTX-2.2pre3 fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB2: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB1: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB0: File exists fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB2: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB1: File exists RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyUSB0: File exists fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile fhs_lock: creating lockfile: 10177 fhs_unlock: Removing LockFile Thu Apr 02 13:41:30 EDT 2009:TIOBoard: java.io.IOException: java.io.IOException: TSerial[22]: Open Failed ***END CAPTURE -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090402/c66f8d70/attachment-0019.html From netbeans at gatworks.com Thu Apr 2 17:15:04 2009 From: netbeans at gatworks.com (U. George) Date: Thu, 02 Apr 2009 19:15:04 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: Message-ID: <49D546F8.20807@gatworks.com> > "z = new Zystem(Zystem.PRINT_MODE);" > Below is capture of the application with debugging enabled. It show > the application hang point, and the second application's printout at the > release point. (pre3 is the locally modified version of pre2) > Any suggestions on how to pin this down further? > Thanks, > +BillJ When perceived runability is hung, try a ^\ ( control \) on console. This gets the JVM to dump the stacks of all the java threads. If you know the thread that is stuck, then u can see what java statement its stuck at. From tjarvi at qbang.org Thu Apr 2 19:25:17 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 2 Apr 2009 19:25:17 -0600 (MDT) Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: <49D546F8.20807@gatworks.com> References: <49D546F8.20807@gatworks.com> Message-ID: On Thu, 2 Apr 2009, U. George wrote: >> "z = new Zystem(Zystem.PRINT_MODE);" >> Below is capture of the application with debugging enabled. It show >> the application hang point, and the second application's printout at the >> release point. (pre3 is the locally modified version of pre2) >> Any suggestions on how to pin this down further? >> Thanks, >> +BillJ > > When perceived runability is hung, try a ^\ ( control \) on console. > This gets the JVM to dump the stacks of all the java threads. > If you know the thread that is stuck, then u can see what java statement > its stuck at. I've also noticed some linux systems hanging with open/read/write and saw kacpid storms. I need to look at it more but did observe kacpid consuming a core and not returning to a normal state for a significant period of time. It was easy to observe from top sorted by CPU usage. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Apr 2 19:26:18 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 2 Apr 2009 19:26:18 -0600 (MDT) Subject: [Rxtx] Windows 64-bit support? In-Reply-To: <49D43979.4050702@bbs.darktech.org> References: <49D43979.4050702@bbs.darktech.org> Message-ID: On Thu, 2 Apr 2009, cowwoc wrote: > Hi, > > I'd like to run RXTX under the Windows 64-bit JVM. Are there plans > to release an official 64-bit version anytime soon? > It is in the prerelease and will be in the final release. I'm pushing it through as fast as I can in my free time. -- Trent Jarvi tjarvi at qbang.org From cowwoc at bbs.darktech.org Thu Apr 2 22:57:34 2009 From: cowwoc at bbs.darktech.org (cowwoc) Date: Fri, 03 Apr 2009 00:57:34 -0400 Subject: [Rxtx] Missing documentation In-Reply-To: References: <49D43979.4050702@bbs.darktech.org> Message-ID: <49D5973E.4050400@bbs.darktech.org> Hi, I noticed that RXTX 2.1 drops javax.comm support in favor of gnu.io. I have one major problem with this: the gui.io.* documentation is very poor. Many classes and methods have no Javadoc at all which makes them difficult to use. Please fix this for the final release. Thank you, Gili From alex.sas at freemail.hu Fri Apr 3 01:36:54 2009 From: alex.sas at freemail.hu (Sas Alex) Date: Fri, 3 Apr 2009 09:36:54 +0200 (CEST) Subject: [Rxtx] Serial port false reads Message-ID: Hi all, On Windows XP, using rxtx-2.1-7-r2 I have a program communicating on a serial line like the following (excerpt): { os.write(command); os.flush(); // Thread.sleep(period); // read response while(is.available() > 0) { is.read() } } If there is a sleep between the os.flush and the reading cycle the correct answer is received. Otherwise (sometimes) there are extra, erronous characters at the beginning of the answer, but the correct answer (according to the protocol) also arrives, afterwards. Is this a normal behaviour, one should wait before the read? If yes, is there a way to determine the minimum amount of time to wait for? Serial port params are: 9600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE. Thank you in advance, Alex ________________________________________________________ El?foglal?si akci? meghosszabb?tva! Korfui ?d?l?s m?r 56.910 Ft-t?l. http://www.budavartours.hu/gorogorszag/?utm_campaign=origo&utm_source=freemail_kimeno_090403&utm_medium=ct&utm_content=korfu_elofoglalasi_akcio#reg_Korfu -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20090403/8f3650ea/attachment-0019.html From bill7007 at gmail.com Fri Apr 3 16:15:30 2009 From: bill7007 at gmail.com (Bill Johnson) Date: Fri, 3 Apr 2009 18:15:30 -0400 Subject: [Rxtx] Serial sometimes hangs on open with newer kernel In-Reply-To: References: <49D546F8.20807@gatworks.com> Message-ID: > When perceived runability is hung, try a ^\ ( control \) on console. >> This gets the JVM to dump the stacks of all the java threads. > > Good idea... A thread dump is below, it looks like only some system threads